Jeremy Ruston

> So the only potential downside I'm aware of to dropping IE support has just been removed. 🎉 Dropping IE support in the Getting Started tiddler, as proposed in the...

Thanks @rmunn that's encouraging. It occurs to me that there are some indications that there are still people using the "HTA hack" for saving under Windows; we get a trickle...

> In terms of naming and syntax for operators, I wonder if something along these lines might be more intuitive: > `[[foobar]json:get[a]]` or `[[foobar]json-get[a]]` instead of `[[foobar]getjson[a]]` I'm not sold...

> OK so a `structjson` operator could be `[[foobar]structjson[d]]` and return: `"d.e:'four'" "d.f[0]:'five'" "d.f[1]:'six'" "d.f[2]:true" "d.f[3]:false" "d.f[4]:null"` The trouble with that is that the resulting strings are pretty much useless;...

> My primary concern is that to the uninitiated, `getjson[]` reads as if it returns JSON. So it is worth trying to think of better alternatives before we settle for...

Hi @pmario > Not really. It's returns key:value pairs in 1 filter run. Whereas "flat" result lists most of the time need 2 or more filters to create useful outputs....

> I'm assuming, of course, the parser knows it's in json-land after parsing "[foobar]". Sadly, it doesn't know the type of the input at the time the filter expression is...

> What about... Interesting idea! But it appears to introduce another new syntax that will need parsing and error checking...

> Yes, I think @pmario is correct, there needs to be an array "signal", otherwise a prop named "2" is indistinguishable from array index 2. Conveniently, there is no difference....

In any case, this PR is about these operators. This discussion about setting JSON properties is outside of the scope of this PR, and should take place elsewhere, please!