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
