Feature: one-off /temporary/single press mode

[BlueDrink9]

The mode system is excellent, but it is slightly different to sxhkd in that it it does not give easy one-off chords. For example, with sxhkd I do

super + e; t 
 kitty

to execute terminal. I do something similar for a bunch of other commands too, often with multiple options etc. With swhkd I would have to do

mode execute
t
 kitty && @escape

That's a fine workaround for a once-off, but becomes very frustrating to do for every chord I define.

This could be enhanced by allowing modes that do not persist (eg mode execute autoescape/nonpersist/temporary/onceoff), but instead automatically pop the stack after the next keystroke. (It would also be wonderful to be able to define a command to run when escaping up the stack in this way).

[BlueDrink9]

As a side note, I tried to understand the parsing system for the config but found it quite difficult. Is there a reason the project isn't using a grammar-based parser? Is it to avoid dependencies or is it lack of familiarity with CF grammars?

[ajanon]

Thanks for the issue!

To answer your comment: I am not sure why it was done this way in the beginning, as I was not part of the team. I agree that the config parsing code is a bit difficult to follow, and it takes some time to get through.

I am planning to write a formal grammar for the config, but haven't taken the time to do it. Once this is done, writing the config parsing code using a separate library will be easier. Quite a few of them exist for Rust: pest and rust-peg seemed interesting, but a lot of alternatives also exist.

[ajanon]

In your previous comment (https://github.com/waycrate/swhkd/issues/67#issuecomment-1278747644) you also mentioned using skhd. Quickly looking through sxhkd, skhd and swhkd, it seems all three try to do something similar but each with a slightly different config syntax.

I wonder if some standardization could be achieved.

[BlueDrink9]

I looked at my skhd config and realised it does modes well but not chords. Sxhkd does chords well, modes ok, but not modes and chords together. I don't see how standardising them will be helpful. You'd lose desirable syntax elements for the sake of compatibility

[ajanon]

Ideally, we could have a single standardized config format for all three applications with all their features and maybe even a common parsing library. This may be hard to achieve, and as you said, maybe not that desirable.

[BlueDrink9]

Replied in #168

[ajanon]

@BlueDrink9 Would you mind taking a look at the newly implemented mode options?

[BlueDrink9]

Will do, sorry I haven't gotten around to it yet (AoC still sucking through my time :sweat_smile: