@RunRevMark: You're right, we should split them up - at the very least when it comes to the implementation.
I mainly wanted to bounce the syntax idea off of the forum readers.
Regular expressions -
looking at other commands and operators
I like the 'matches' operator idea as it would nicely complement 'begins with' and 'ends with' - but I'm not sure about the idea of having to add 'pattern' wherever I use 'matches' or 'matching'. The 'replace' command has a 'replaceText' function counterpart with regex support.
Then again, adding 'pattern' throughout would make for consistent syntax. How about making it optional syntactic sugar for 'matches' and 'matching'?
Code: Select all
filter <container> [ not ] matching [ pattern ] <pattern>
x matches [ pattern ] <pattern>
replace pattern <pattern> with [ pattern ] <replace_pattern> in <container>
Come to think of it, surrounding certain operators with a 'not' and parentheses also looks a bit clunky, so the following might be nice too:
Code: Select all
x does not match [ pattern ] <pattern>
x does not begin with <prefix>
x does not end with <suffix>
But that's definitely out of the scope of this discussion...
Into clause -
incorporating semantics from 'convert'
Thanks for pointing out these semantics of the 'convert' command; they're not described in the docs but definitely handy!
And it does sound like a very fluent way of coding for the developer.
Thinking out loud, these semantics could also apply to the 'split' command - but that's perhaps a bridge too far and again out of scope...
Other chunks -
let's limit this to 'items'
I didn't want to go the whole way, just the ability to filter items as this would match the sort command capabilities and is straightforward to implement.
Code: Select all
filter [ { lines | items } of ] <container> ...
Other chunk types would definitely be a headache for the reasons RunRevMark mentioned.
Combining it all -
into a single syntax definition
So when we combine the above we would come to the following new syntax for the 'filter' command.
Code: Select all
filter [ { lines | items } of ] <container_or_exp> { { with | without } <filter_pattern> | [ not ] matching [ pattern ] <regex_pattern> } [ into <container> ]
Definitely food for multiple feature branches
Jan Schenkel.