Introspecting key bindings (mapping them to configuration)

[johnrichardrinehart]

I've seen Mod+Shift+? which renders an "Important Hotkeys" modal.

1. I want something like this for all possible bindings.

2. Another related thing I would want is the ability to have niri tell me which action is related to a binding when I execute it. So, either display something like through notify-send (pop-up/notification to screen) or something within a terminal kind of like xev.

In the case of 2. a nice extra would be to tell me which configuration line defines this (or if it's built-in/default).

[Sempyos]

..I do feel this a little out of scope for niri, however, a good alternative for you to look at would be wlr-which-key

[johnrichardrinehart]

Yeah, that's a cool little tool. But, how would you generate the configuration for that (dump all niri keybindings). The problem is that I'll hit key bindings on accident and not be able to easily find them in my config. Because I searched for Mod+ instead of Super+ or I forgot to escape + in grep, which isn't necessary when I'm searching in vim, or because I searched the root configuration file instead of the included ones (or because the included one overrode the value in the parent, or vice versa).

When you say "this is out of scope", what's "this"? Maybe you mean both 1. and 2., or maybe you only mean 1. or only 2. I'm trying to understand what is out of scope and why.

[Sempyos]

Hm, I feel you could probably manually use custom hotkey overlays as seen here:
https://yalter.github.io/niri/Configuration%3A-Key-Bindings.html#custom-hotkey-overlay-titles

I just feel it's not niri's responsibility to uh show you what keybinds you or the default do besides the simple descriptions provided within the overlay

[johnrichardrinehart]

The custom hotkey overlay requires maintenance. Basically, whenever you press some key sequence that niri would act on, given the niri build and the user's configuration, it has the ability to report on what it would do (or is doing). I think it's reasonable to provide some functionality that informs the user what that would be (or is) by hooking into the lifecycle before triggering the action after having had matched on some event (3 finger touchpad swipe, or key binding, or whatever).

It's definitely not in niri's current set of responsibilities. But, I'm not convinced that it ought not be. I don't see any rationale for that, anyway. And, I don't think it's a lot of effort to provide a feature that explains what's happening when a user triggers something. And, it might ought to should be a responsibility of the tool which acts on human interface events (to report what's triggering what).

[heyoeyo]

Might be relevant: #2980

As a partial short-term solution, you can separate your keybinds into a dedicated .kdl file, and then set up a keybind to pipe this into fuzzel, in dmenu mode, to make it searchable. Something like:

Mod+Shift+Slash { spawn-sh "cat /path/to/keybinds.kdl | fuzzel -d"; }

This will also include comments/blank lines etc, though using the search feature mostly gets around this. The junk lines can also be parsed out (here's an example script). With parsing the keybinds don't even need to be in a separate kdl file.

It would be nice if niri included a built-in print out of the keybinds it ends up with though (e.g. niri msg binds) so this kind of error-prone parsing wouldn't be needed...

[johnrichardrinehart]

Oh, interesting. This is my first time seeing https://github.com/stefonarch/niri-settings/issues and thanks for creating/linking the example script.

My undestanding of niri is that even if my binds {} configuration block is empty that certain keybindings will still be present (the built-in keybindings that you mentioned). And, configuration can be layered, so if someone includes my keybinds.kdl and then layers on their own binds {} to tweak a couple of things then tools like this won't really work. I really just want niri to support dumping all registered bindings at "current time" (even if that might might might change across 500ms watcher reloads) and also allow me to understand what the keybinding I'm pressing would do, without taking the appropriate UI action (dump the body of { ;} for something like

Mod+Shift+Slash { spawn-sh "cat /path/to/keybinds.kdl | fuzzel -d"; }

so that I would/could see spawn-sh "cat /path/to/keybinds.kdl | fuzzel -d" (and, hopefully, something like /path/to/keybinds.kdl:l38).

[heyoeyo]

configuration block is empty that certain keybindings will still be present

There are at least the mouse bindings (e.g. Mod+left/right drag), though I'm not sure if there are others? Would be good to know.

And, configuration can be layered, so if someone includes my keybinds.kdl and then layers on their own binds {} to tweak a couple of things then tools like this won't really work

This could be done in a parsing step, but ya another good reason to have a built-in way of reporting the parsing that niri would have already done.

allow me to understand what the keybinding I'm pressing would do, without taking the appropriate UI action

If there was a built-in IPC way of suppressing the next niri action while reading the keypress, then this could be done fairly easily (basically just automating the fuzzel/fuzzy-find look-up and displaying it). There is an existing toggle-keyboard-shortcuts-inhibit action, though I don't understand what it does, it does make it seem like there could be keypress suppression already built-in.

[johnrichardrinehart]

These are great ideas. Thanks for iterating with me on this. I'll keep this open in case other people want to chime in or in case I (choose to) make any progress.