which-key: `H ➜ Home line of window (top)` and `L ➜ Last line of window` are displayed in one level up

[osamuaoki]

Checklist Please confirm you have run the following commands and restarted Neovim and are encountering the issue with the current latest version of AstroNvim

• [v ] :PackerSync
• [v ] :AstroUpdate
• [v ] restarted AstroNvim
• [v ] Neovim version >= 0.7.0

Describe the bug

which-key as configured by AstroNvim uses unmodified data of "Presets" of which-key upstream.

Thus H ➜ Home line of window (top) and L ➜ Last line of window are displayed.

To Reproduce Steps to reproduce the behavior:

1. Start system
2. Type SPACE to get which-key menu.
3. TYPE Backspace to go up one level
4. See H ➜ Home line of window (top) and L ➜ Last line of window are displayed.

Expected behavior H ➜ Left tab and L ➜ Right tab should be displayed since this is how AstroNvim behaves.

Screenshots NONE

Additional context If this can be solved by user configuration, example pointer somewhere as document may be one solution. (Because people may change other bindings and this is robust than creating and maintaining complicated code.)

[mehalter]

Thanks for reporting. I have investigated this and am sure this is a bug with which-key as we are completely overwriting these descriptions and can be verified with other means like Telescope. I will be opening an upstream issue to hopefully get this resolved.

[mehalter]

In the mean time, I will leave this open just in case anyone else comes to ask about this issue and doesn't search through past issues.

[osamuaoki]

I haven't investigated much but I found a work around to get the native nvim behavior for H and L via user config. (Then which-key becomes correct)

  polish = function()
    -- To regain the original (n)vim feature, unmap is a possibility 
    local unmap = vim.api.nvim_del_keymap
    -- bufferline has picker, so don't kill native vim bindings
    unmap("n", "H")  --Now this moves to HIGH top cursor
    unmap("n", "L")  -- Now this moves OW bottom cursor
 }

Considering this worked, I thought this may be caused by bufferline. But I don't find any strange thing there.

telescope does some binding change in plugins/telescope.lua but that can't be the one causing problem or is it? I don't understand what is all about nui. Is it related? bufferline tab selection and telescope selection ???? No idea.

[osamuaoki]

mappings definition in configs/telescope.lua is what I was looking at. Hmmm... it lacks desc definition.

neo-tree is similar.

but mappings in configs/lsp/handlers.lua has desc.

Since all these access vim.map, what kind of care do we need?

[osamuaoki]

Disabling telescope setting didn't solve problem.... who set these H and L to non-standard values?

I think which-key shipping with vim default mapping desc can't be blamed.

[mehalter]

We set <S-h> and <S-l> in the core/mappings.lua file. I have also tried switching those out with mapping H and L directly but it doesn't change anything which is why I think it has to do with a bug in which-key.

[mehalter]

When we override these mappings, the descriptions should be updated as what happens with other mappings we override in the default configuration.

[osamuaoki]

Aha, I totally overlooked the fact that vim is a case-insensitive world. Sorry.

I see now why this is which-key bug. Thanks.

(I am fine with your intentional choice of <S-h> and <s-l>.)

Osamu

[mehalter]

I'm going to go ahead and close since it is upstream