On Thu, Nov 18, 2021 at 03:31:46PM +0000, Thomas Adam wrote: > On Thu, Nov 18, 2021 at 02:19:11PM +0100, Dominik Vogt wrote: > > Most of the tests were meant to catch parsing bugs, leaks and > > crashes. A mor organised approach in the future would be good. > > Maybe it would even be possible to generate test cases for > > commands programmatically from the BNF. > > It might be -- although my faith in our accuracy of the BNF notation we came > up with isn't too strong.
Of course - the (long term) goal should also be to change the syntax of unmanageable commands so that they can be handled in BNF without much trouble. > Either way, I'll put something together which will > make it easy to expand. Thanks. > I think you're right though, Dominik, we need to pull this into a .md file and > start fleshing it out (similar to how we did the BNF work), if you're happy > for that? Indeed. > > Taking it a step further filters can be applied to *any* command > > line, not just commands: > > > > foobarfunc --match-resource "xterm" > > > > (Problem: How can we distinguish between general filters and the > > actual command/function arguments?) > > If a command in a complex function isn't overriding the calling filter, then > use that? I mean regarding parsing. If filters are universal, they shouldn't be part of the command syntax, and the parser needs to figure out which arguments are filters and which belong to the command, e.g. by a rule that filter arguments must always be placed before other arguments on the command line. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
