bug: Breaks built in mappings

[mehalter]

Did you check docs and existing issues?

• [X] I have read all the which-key.nvim docs
• [X] I have searched the existing issues of which-key.nvim
• [X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.10.0 (github release)

Operating system/version

Arch Linux

Describe the bug

It looks like something changed in the processing of mappings in the v2 release that breaks built in mappings such as << to de-indent.

E5108: Error executing lua ...bug/.repro/plugins/which-key.nvim/lua/which-key/util.lua:44: Invalid 'str': Expected Lua string     
stack traceback:                                                                                                                  
        [C]: in function 'nvim_replace_termcodes'                                                                                 
        ...bug/.repro/plugins/which-key.nvim/lua/which-key/util.lua:44: in function 't'                                           
        ...bug/.repro/plugins/which-key.nvim/lua/which-key/keys.lua:136: in function 'get_mappings'                               
        ...bug/.repro/plugins/which-key.nvim/lua/which-key/view.lua:278: in function 'on_keys'                                    
        ...bug/.repro/plugins/which-key.nvim/lua/which-key/view.lua:246: in function 'open'                                       
        ...bug/.repro/plugins/which-key.nvim/lua/which-key/init.lua:44: in function 'show'                                        
        [string ":lua"]:1: in main chunk

Steps To Reproduce

1. nvim -u repro.lua , use the minimal reproducing config below
2. <<, binding for decreasing indentation
3. See error.

Expected Behavior

No error and all default mappings should still work.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  { "folke/which-key.nvim", config = true },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

[folke]

Can't reproduce with the repro. Are you 100% you're on the latest version?

[mehalter]

Please try again, the minimal repro.lua above reproduces the bug perfectly. Here is a recording showing me doing a fresh installation given the code above and walking through:

https://asciinema.org/a/eDq77UjzMbI7GCzwSs8TnraHT

[mehalter]

NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info

Here are the full version details of the neovim version I am using

[mehalter]

NVIM v0.11.0-dev-189+g78d3f4742
Build type: RelWithDebInfo
LuaJIT 2.1.1716656478
Run "nvim -V1 -v" for more info

I have verified that I can also reproduce with the latest nightly

[folke]

I you run that repro, make sure to update the plugins in the repro as well

[folke]

nm, you deleted the files

[mehalter]

I have verified that I am on the latest.

[folke]

so weird, it all works fine for me

[folke]

https://github.com/folke/which-key.nvim/assets/292349/0cae648d-ea02-4728-9cc0-85c2d23a1e40

[folke]

ok, can reproduce now. First >> then << triggers the error

[mehalter]

Do the other way...

[mehalter]

I also agree that >> works as shown in my recording

[folke]

bisected it to https://github.com/folke/which-key.nvim/pull/600

Will check or revert

[folke]

reverted for now. had a quick look at that code and it's wrong for sure. will implement it myself

[mehalter]

Thanks! Definitely strange you have to indent first, on my end if I just do the exact steps I put in the issue and run << even as the first thing in the editor I get the problem

[folke]

I reverted the PR and just did a proper fix for those nested operators.

[folke]

Thank you for reporting!