Allow suffixes for filter runs

[saqimtiaz]

Allows for suffixes to filter run prefixes, as discussed in #5166
Also see here

@Jermolene Suggest we delay this for 5.1.24 since no core prefixes use this at the moment, and thus we can have more time to make a considered decision and test more thoroughly. Just pushing this PR now so I do not forget.

[saqimtiaz]

An open question is whether we would want to support multiple suffixes?

[Jermolene]

An open question is whether we would want to support multiple suffixes?

I think that would be consistent with the existing (newer) operator suffix syntax.

[saqimtiaz]

@Jermolene I thought as much and it doesn't hurt to have the support there even if we don't necessarily use it right away.

I will re-work this PR to support multiple suffixes post 5.1.23

[rmunn]

One core named prefix, :reduce, might be able to benefit from suffixes so that users can specify the starting value for the accumulator (e.g., the :reduce:1[multiply<accumulator>] example). Though for :reduce, what it really wants is a second parameter the way the reduce operator takes a second parameter, because that would allow specifying the starting value from a variable or a transclusion. A suffix would only allow literal values to be specified, which helps when you want a starting accumulator value of 1 but doesn't help much when you want a starting value of <currentTiddler>.

But that's not a reason to squeeze this into 5.1.23. I agree with delaying it until 5.1.24.

[saqimtiaz]

@Jermolene I have extended this to accommodate multiple filter run prefix suffixes as previously discussed. As a recap, after some discussion we had agreed to implement suffixes for filter runs.

:sort:suffix1:suffix2[... filter ...] or :sort:suffix1a,suffix1b:suffix2[... filter ...] are now possible.

• The syntax supported is exactly the same as for the rich suffixes for filter operators.
• I've added tests for named filter run prefixes, without and with suffixes.
• Once this is merged I can extend :reduce to use a suffix and also work on the :sort filter run prefixes.
• Once we have examples in the core that use these suffixes I will update the documentation.

[saqimtiaz]

With regards to the alternate proposal for a syntax like :subsort[... filter ...],[suffix] , I think this is far less easier to read and comprehend. Given that filters can get rather long, the suffixes for a filter run prefix can end up really far away from their prefix, and you don't understand what the filter run is doing until after you get to the end.

Compare the following (please disregard the logic of the filter, its just an example of a longer filter run):
:subsort[get[myfield]enlist-input[]removeprefix[$:/sq/plugins/sort-criteria]then<1>else<2>],[number]

:subsort:number[get[myfield]enlist-input[]removeprefix[$:/sq/plugins/sort-criteria]then<1>else<2>]

With the latter, it is immediately understood how the filter run will be applied, whereas with the former you don't realize this until after reading the entire run. While the former syntax might seem familiar to the developers amongst us as it resembles passing arguments to a function, I think for most of our users the latter will be far easier to understand.

As for being able to use variables as suffixes, currently our parser doesn't support either of the above two syntax. So support for variables isn't a given in either one, and could be implemented for either if so desired.

Also, I think it would be acceptable for each way of filtering to have its own strengths. For example comparing the subsort[] filter operator to a :subsort filter run prefix, the operator needs a variable for the filter, whereas the filter run prefix does not but cannot pass a variable to the suffix. Users can choose whichever is most convenient for their use case.

[Jermolene]

Sounds good thanks @saqimtiaz, I'll have a look at the code.

[Jermolene]

Fantastic, thanks @saqimtiaz