Michael Färber

> 😬 as tradeoff i promise to spend more time with rust! actually started looking into adding some stuff to jaq but maybe looking into support "shorthand" object literals `123...

More generally, I think that the general approach to parser iterators in 1.0.0-alpha.4 can be improved: * It would be awesome if we could actually use `IterParser` more like [Iterator](https://doc.rust-lang.org/std/iter/trait.Iterator.html#)....

Yet another thought: `or_not` returns an `Option`. It would be nice if we could somehow translate a `Parser` into an `IterParser`. Like `Option::into_iter`. That would help parsing `a?b*`, where both...

Yet another idea: It might be a nice idea to be able to convert `Iterator`s to `IterParser`s, such that yielding the next element would not perform any parsing. This would...

For now, I have reverted your previous PR, @baod-rate, because of the change in jq. I think that it would be great to have some option to set the "output...

This is a [known restriction](https://stackoverflow.com/a/57497310) of the regex library that jaq uses. As suggested in the linked post, we could use in jaq Rust bindings to oniguruma, the regex library...

I would say that this issue scratches the top of the iceberg, because the behaviour of multiple values for regex filters is quite strange even within jq itself. Observe: ~~~...

When I'm already at it: The next source of confusion is implicit global search. For example, I just discovered that `match` does not imply `g`, whereas `scan` does: ~~~ $...

> I would propose to fix an evaluation order for all regex filters (`test`, `scan`, `match`, `capture`, `split`, `sub`), namely evaluating arguments from left to right. That means that for...

> 1. Evidently you meant: `(? … )` Yes, thanks for spotting this! > 2. `E | gsub($string; stream)` should be just `E | stream as $s | gsub($string; $s)`,...