swhkd
swhkd copied to clipboard
waycrate
Feature: one-off /temporary/single press mode
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).
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?
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.
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.
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
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 Would you mind taking a look at the newly implemented mode options?
Will do, sorry I haven't gotten around to it yet (AoC still sucking through my time :sweat_smile: