Add a column to a list of commands and allow changing their descriptions

[eugenesvk]

Helix has this nice feature of showing you a list of commands to pick from with a short description, for example, in "Space mode" you'd see:

p Paste clipboard after selections
P Paste clipboard before selections

However, to make the selection even easier, I'd prefer to add another vertically aligned column of icons, e.g. 📋 for the commands above

In addition to that, I'd like to be able to edit the command descriptions themselves to make the wall of text look nicer, e.g.:

• significantly shorten them or remove altogether (if the "icon" is all that I need) and
• vertically align to see the differences easier

So the example above could become something like this:

p 📋⤹	Paste clipboard after  selections
P 📋⤸	                before

(ideally the order should also be something that I can control so that before would always come before after :) )

Also, it'd be great to be able to customize the shortcuts as well, e.g., the left column below with icons for modifiers is much better vs. the old tradition of using alphamod-Key style

  symodKey	alphamod-Key
  ⇧ a     	A
   ⎇a     	A-a
  ⇧⎇a     	A-A

[NNBnh]

Although this is very intuitive, in some cases when the system/terminal doesn't support emoji, this will make a weird gaps or an error symbol. This should probably be off by default, though I wish we can make a mechanism to detect emoji support.

I also have a question: what will the icons for hover, rename_symbol be?

[eugenesvk]

be off by default

certainly it will be (at least that's what I had in mind) — the abbreviations come from a user's config file, so if he hasn't added any, nothing will be shown — there won't be an extra column

Though you got me thinking — this kind of formatting might be universally better, so maybe it might make sense to include it by default?

Then

I wish we can make a mechanism to detect emoji support.

would help avoid the ugly gaps

I also have a question: what will the icons for hover, rename_symbol be?

whatever you want, it's your popup :) !
If we're limiting ourselves to no-GUI text, there might be nothing "universally" good (I'm using a simple ? for hover), and for symbol rename you could use

• ⚛✎ where symbol is an atom of a programming language and rename is a pencil (or maybe a fancy
• 𝖗 is fine for you)

Down the line in the GUI you could design anything better

[7ombie]

In #9829, I suggested allowing users to customize menus with a simple, multiline string. That would be simpler than this proposal, and it solves all of the issues with customizing menus, including all of the stuff above, and preempts future feature requests (by allowing for completely arbitrary content). We should just do something like that instead.

[eugenesvk]

Text fails at solving the most basic future issue: tabular alignment, which will rear its ugly head with GUIs and proportional fonts. For the fixed-width terminals that's not a big deal even though some emojis already don't properly fit in one cell, but that'd just waste an extra blank cell

Then you'd have to repeat all keybinds (and keep changes in sync, which is especially challenging with many keys) instead of adding descriptions to existing ones and use the other field as is and getting the order that already exists

Then it's harder to apply consistent per-column styles

These are just some of the benefits of typed data vs untyped blob of text

[7ombie]

Text fails at solving the most basic future issue: tabular alignment, which will rear its ugly head with GUIs and proportional fonts. For the fixed-width terminals that's not a big deal even though some emojis already don't properly fit in one cell, but that'd just waste an extra blank cell

You seem to acknowledge that this is a non-issue. We only use monospaced text in Helix menus, and you're not shipping these menus. They're user-specific customizations.

Then you'd have to repeat all keybinds (and keep changes in sync, which is especially challenging with many keys) instead of adding descriptions to existing ones and use the other field as is and getting the order that already exists

Why?? The keybindings don't change. You're only customizing the menu-text, and stating which binding prefixes a given menu-text. For example, I could do this to customize the Space Menu:

[keys.normal.space]
menutext = ...

The bindings are unaffected.

Then it's harder to apply consistent per-column styles

I'm not sure what this is about? Could you give an example, please?

To be clear, I'm not saying to never provide conveniences that make it easier to tweak menus. I'm arguing that a simple string does everything you need, so anything else (like #1474) would always be a convenience. I'm not personally convinced that #1474 provides much convenience, but maybe I'm just wrong about that. Either way, I think we should support a simple string, and then consider also supporting stuff like #1474 as improvements over just using a simple string.

[eugenesvk]

You seem to acknowledge that this is a non-issue.

I do not, especially given your forever-future-proof claim

The keybindings don't change.

Unless you change them, and then would need to update in two places: one in the menu text, another in the keybinding itself. But even for the first iteration you'd have to copy all of your keybinds to add extra text. Then what if you want to change the description for only 2 keybinds (and hide 5) out of 100? How does plain text know whether you've changed the whole menu or just a few keys?

Style examples:

• center-aligning of the emoji column, right-aligning the keybinding column, left-aligning the description column
• making each regular key in the keybinding column bold.
• color the key combos for delete operations red (but not other columns)

[7ombie]

I do not, especially given your forever-future-proof claim

How is an arbitrary string not future-proof? Anything you want to add to the menu, you can add, whether that's something people already asked for, or something they ask for in the future. That's all I meant - it's totally open ended.

Unless you change them, and then would need to update in two places: one in the menu text, another in the keybinding itself. But even for the first iteration you'd have to copy all of your keybinds to add extra text. Then what if you want to change the description for only 2 keybinds (and hide 5) out of 100? How does plain text know whether you've changed the whole menu or just a few keys?

The Helix docs would contain a section that explains how to update menu text, with a small appendix that contains the standard text for the default menus. So, users would just copy that into their config file, and modify it as required.

Again, this a generic solution. It doesn't preclude providing conveniences as well.

center-aligning of the emoji column, right-aligning the keybinding column, left-aligning the description column

This is all doable with a simple string.

making each regular key in the keybinding column bold.
color the key combos for delete operations red (but not other columns)

This is not possible now, so would require enhancements to how Helix menus work. Naturally, if we were considering adding highlighting to menus, I would recommend supporting markup strings to achieve the same effect, maybe using a different key in the config file, so we'd have menutext and menudoc or something like that.

By the way, I'm not at all sure this is the right API:

[keys.normal.space]
menutext = ...

I just like the idea of having an arbitrary string as a basic option for customizing menus. I haven't thought about the details beyond that. #9829 was only about listing the limitations with custom menus in Helix in general. I later floated using a simple string as one thing to consider.

On reflection, you do have point about generating better looking keybindings (symod vs alpha mod). That would be useful, so I'm sorry for claiming the whole proposal lacked convenience. I can see some merit in it (again, though, as a convenience).