Custom Indexing (and potentially extended kb-select bindings)

[yuki-tsubaki]

Background

As a lover of the Vim philosophy around keybindings, i.e. use one specific command over multiple general commands, I love the idea of key bindings that automatically select a given index from the list without having to filter or use arrow keys.

While I love the concept, I feel that two things hold rofi back in this regard:

1. Rofi has a single unchangeable set of characters that it can use to display the indexes—these numbers 1234567890.
2. Matching these indexes, rofi only allows for 10 kb-select commands (which correspond to these index numbers.

I think this selection method would be much more powerful if users could change the character set used to label the indexes and, if reasonable to implement, have a dynamic number of index labels and corresponding kb-select keybindings.

Use Cases

In my case, I would like to use home row letters and a few other easy to reach characters in my select commands along with a set modifier key for all of them. If possible it would be nice to have more than 10 indexes so I can launch my most commonly used programs in 1 key-chord from combi mode even when I have many windows open (although it would be nice even if I could use just 10 with custom index labels).

Right now the index feature feels like it is stuck in an awkward position—it only really fits in themes with exactly ten lines, and the people who would be most likely to use it (keyboard-everywhere, TWM and Vim/Emacs users) are also the most likely people to feel limited by the inherent tie to numerical indices.
In general, expanding the index selection functionality could take it from feeling like an awkward afterthought to a versatile and powerful feature.

Examples and Potential Implementation

As an example of a program that does what I am requesting here, this is a screenshot of my Japanese input method, skk (using fcitx5, although it was originally made for Emacs in the 80's) .

https://i.postimg.cc/Xv0tVw6b/nice-completion.png

I don't need to tab/scroll through the options shown, I can just press one letter to select what I want

As for implementation, the programs that I have seen that use custom character sets for selection (Tridactyl and Nyxt come to mind) use functions to map the keys to the actions which contradicts how you seem to handle all the other bindings (if I am right that this is done in keyb.c). However even if it isn't reasonable to use a dynamic key-binder, simply adding a configuration option where you can give a list of index characters would make non-numeric kb-select much more viable.

[DaveDavenport]

I think I understand what you want. I don't directly see a clean/simple way to implement this as it is done in tridactyl/nyxt/cutebrowser.
With the hint boxes and easy keys:

A quick way to achieve something very similar would be possible and is probably reasonably easy to implement is adding a combi like mode (e.g. a mode that wraps other modes) that shows for each entry one of these 'matching strings' . In its custom matching method it only matches on these. Then this together with the auto-select option should do what you want. You use the current entry box then to enter the 'matching string' (unsure how to call this).
I would accept this into rofi as it would be pretty isolated from the rest (and can even be a (c) plugin).

To 'fully' integrate it as above would be more work, as currently all input (except the bindings) go to the entry box. But, on a keybinding? redirecting this into the 'matcher' would not be impossible. Even drawing the 'highlight boxes' as in the above screenshot should be possible in the current framework.
I am not sure if this is something I really want to add, it feels like a lot of extra code (that needs to be maintained) for possibly a small user base.

Is there a common 'algorithm' to make a list of these matching strings? I assume they are weighted in some form so more often used entries have a shorter 'string' and optimized to have the least number of key strokes on average for the number of entries shown.

[yuki-tsubaki]

Oh, those references were probably misleading. I don't think rofi needs anything that complicated. Full on hinting like that is (in my opinion) most useful when you need to add a keyboard interface to something that was designed for mice (or I suppose other location based input like touch). The most obvious example would be the Internet (e.g. you have a site with a list with a plain text description and a hyperlink at the end with the display text 'here' or something like that--you need hints to quickly disambiguate textually identical links.

I didn't mean providing unique hint characters for all the results. The screenshot of my input method was much closer to the scale I was thinking. The only reason I brought those examples in is because they have an analogous configuration method (in Tridactyl the variable hintchars and in Nyxt the slot hints-alphabet is a string giving the set of characters to be used in hints).

Better Description of the Core Request: Index Character Substitution

The core part of the request would involve adding a similar variable, say index_chars, to the config where a user could give a string of characters to display as the element-index. For example, a value of 1234567890 would correspond to the default index behavior, changing value to asdfghjklp would be similar to the current behavior, but using 'a' in place of '1', 's' for '2' etc. I was thinking that this might be possible by something as simple as using index_chars[i] in place of i as the element-index text (although this is just an assumption because I wasn't able to find the actual place in rofi's code where the element-index characters are added).
This alone would make kb-select bindings significantly more useful for me as setting bindings like <C-[a|s|d|f ...]> would correspond to the displayed index.

Potential Enhancements

Display as many indexes as characters in index_chars

This would basically be a continuation of the core feature only differing in that this stops indexing when the characters in the index_chars run out rather than at ten. This would facilitate, but not require keybindings to select a specific index.

Extended kb-select bindings

Basically having more than 10 kb-select type. Personally I would want to use 15. I tried it out by adding a kb-select-11 binding and it worked fine for me.

Tangent on Hint String Generation Algorithms

(On an unrelated side note, if you were wondering, I did get curious and looked at the code for the hint generation for Tridactyl and Nyxt (not Qutebrowser because I'm not as familiar with it), and they seem to use different but related methods (both of them are weighted). I think I understood Nyxt's implementation best. It involved selecting characters from a virtual tree (actually an array with the the hint character set) with nodes being one of the characters in the hint-alphabet. They did basically did it with some fancy pointer arithmetic. For Tridactyl what I understood/remember was that they made an iterator to be able to generate all permutations of the required number of letters, and prune it to make it shorter.)