folke / which-key.nvim

💥 Create key bindings that stick. WhichKey helps you remember your Neovim keymaps, by showing available keybindings in a popup as you type.
Apache License 2.0
5.12k stars 163 forks source link

feature: decorate descriptions with highlighting, color-changing, etc. #801

Closed Ben-PH closed 4 days ago

Ben-PH commented 1 month ago

Did you check the docs?

Is your feature request related to a problem? Please describe.

I wish descriptions could show, rather than describe, a keybinding.

Here are some "upgrades" to the desc field that hopefully illustrates at least the idea behind the feature:

Describe the solution you'd like

From my reading of documentation, brief perusal of how plugins highlight ui-text, perusing search engines and seeing what ChatGPT had to say, I would guess that what I am proposing is deceptively difficult.

Ideally, I would be able to put some standard formatting characters around the text, such as using ANSI, and that would JustWork^tm. failing that:

some sort of interface where you can use some sort of format string to fine tune string decorations:

{bold;foo} bar -> foo bar {bg:0xdead44, fg:0x12ab44;hello world} -> "hello world" but wth the hex colors used for setting background and foreground

under the hood, one possibility would be to edit the color scheme to append a new highlight group, and somehow attach the chosen text-segments to said group? honestly, at that level, I am way out of my depth.

Describe alternatives you've considered

I'm not familiar with any existing solutions/frameworks that that allow you to ergonomically decorate ui text with highlighting, bolding, etc in a "global" way. From what I gather, it's non trivial to do this: it involves deriving and tracking text positions, managing context and updates, etc. I suspect this might be more of an nvim-thing, where the goal would be to expose an ergonomic interface that's built into nvim directly.

One possibility would be to add an additional

Additional context

Hope you had a nice holiday :)

max397574 commented 1 month ago
  1. I don't get what you mean by the examples
  2. it makes no sense to use escape sequences or anything similar in neovim. Imo what would make the most sense is being able to provide a table like you pass it to set extmarks which contains tables of text, hl chunks
Ben-PH commented 1 month ago

I don't get what you mean by the examples

Suppose you have a binding that has the description "visually select the rhs of the next assignment operation" (provided by treesitter-textobjects). To read what the keybinding for that does is useful, but what would be particularly handy, is to see what it would do.

Instead of a description in the literal sense, you can add visual cues to the descriptions.

M.some_fn = function()
--        ^ cursor here
end

to show the WhichKey window at this point with the binding mentioned, the description would look more like "let lhs = rhs"

I'm limited with text rendering here. Imagine the bold part looks like it's been selected under visual mode, but ideally, it would visually prompt "if you use this keybinding, the effect will look like this"

...even better, the prompt might look like "M.some_fn = function()" (but that's probably out of scope of this feature request)"

Additionally, you can add various visual cues to your descriptors, and it can present patterns that reduce cognitive load. If you have organised bindings for searching under <leader>f, there's different classes of search: lsp, grepping strings, searching files, searching marks, etc. You might set all LSP commands to be LSP: <actual search>, This feature would allow you to group the LSP: prefix with a common visual cue (bg-color, for example).

At the high-level: the cognitive task of parsing information presented by the whichkey window is eased by allowing the use of visual cues through a colorscheme-like mechanism.

it makes no sense to use escape sequences or anything similar in neovim. Imo what would make the most sense is being able to provide a table like you pass it to set extmarks which contains tables of text, hl chunks

This is where this post starts getting out of my wheelhouse, and I doubt I can add any value to that aspect of the discussion.

max397574 commented 1 month ago

imo this is completely out of scope because it's likely require rewriting a big part of the plugin to allow dynamic labels

but in the end that's up to folke

Ben-PH commented 1 month ago

That's probably reasonable. My take at this point is that this sort of thing would be handy generally, but would be particularly applicable to whichkey. There are, of course, means for plugin developers to decorate their text to present visual cues, but whichkey is particular in the sense that plugin users are expected/empowered to define the text in their UI.

github-actions[bot] commented 1 week ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

github-actions[bot] commented 4 days ago

This issue was closed because it has been stalled for 7 days with no activity.