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. Either way, I'll put something together which will make it easy to expand. > Sounds interesting. While implementing new ways of selecting > source/target (what is the difference?) it is still possible to > keep the existing conditionals working: If "-s ..." is present, > use it. Otherwise use the window that has been selected by a > conditional. If that's not defined either, ask the user to select > one. Yes, in that order as well, I would have thought. I'm still mulling over what I mean by source vs target, but source refers to the window or windows which the command needs to operate on, and target is the end result of that command. Take the `Move` command, for instance: Move -s <filter> -t screen|desktop|page But I think that's overcomplicating things. What matters is whether the command expects a window, or if it's a command which changes state (such as a colorset, or a setting for something). 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? > For multi-target conditions the syntax would work too. > > Old way, loop over all windows, filter them by a resource name, > then apply a command to them: > > All (xterm) Close > > Same in new syntax (assuming "-c" marks the beginning of the > command to execute): > > All --match-resource "xterm" -c Close Something like that, yes. Although I'm suggesting that filters would allow for us doing away with commands such as: All, None, Next, Prev, as they'd become a part of the filter. So you might say: Close --filter "screen:X,desk:*,class:XTerm,condition:*" ... to close all XTerm windows (condition:*), which were only on screen X, all desks (desk:*). Either way would work though. > 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? > Note: Complex functions already have a kind of filtering with the > "I", "C", ... bits. Yeah -- this needs more thinking. Hmm. Kindly, Thomas