I am using a different which key plugin than was mentioned in those pr's. I have been using Plug 'liuchengxu/vim-which-key' but I guess I can switch to the other one if that is advised.

Hmm

So

I'm not integrating which-key in any way, I'm just adding a desc key to the mapping data, it's passive data that plugins use if they want to. I'm also upgrading each definition of every mapping to the new Lua APIs, this means I can map a mapping to a Lua function directly, rather than to some VimL that calls a Lua function (which caused a few bugs). So this is an essential change to use the modern nvim 0.7+ APIs and fix a bunch of weird interactions.

What I think is happening is the new nvim API defines mappings without a .rhs property, which I guarded against inside Conjure's code.

I think there's some plugins out there that are now running into the same breaking change (which is kind of a nvim breaking change)

Mappings defined with the new Lua API don't have a .rhs property, so you can't just try to look it up blindly now, it'll throw

I think this is a which key bug, but I'm not 100% sure.

I say bug, but really what it is is yet more nvim ecosystem breaking changes which forces plugin maintainers to constantly keep up.

Ok. Sounds like a good time to switch to this more "modern" which key plugin.

Yeah, I did that a while back and it works just fine as far as I can tell

I just installed it and forgot about it I think

(maybe I had to require and .init() it, but that's all?)

Ok, because it seemed more involved to me.

Like just this right here

" Vim Script
Plug 'folke/which-key.nvim'

lua << EOF
  require("which-key").setup {
    -- your configuration comes here
    -- or leave it empty to use the default settings
    -- refer to the configuration section below
  }
EOF

I haven't switched over to a Lua config yet so will that just work in my init.vim?

But yeah, I'm not like calling any which-key functions etc, so it's not like I'm doing some active integration, I'm just tacking a description onto my mappings. But I think it's the new API usage causing issues with older plugins

Yeah, you can just do :lua require('...') etc

Embedding Lua in VimL works fine

So just lua require('which-key').setup({}) should do it? I think

Or use their EOF heredoc thing

Sorry about forcing your hand into a plugin change 😞 I also had another plugin run into similar errors for a while until they updated to guard against this missing value

And Conjure had issues with it until I updated it. I guess it's a thing maintainers are slowly realising.

Oh no worries from your end. I wish the vim/nvim folks had found a way to keep things compatible but it seems in the last few months that has finally broke and they will be diverging from here on out. I just keep avoiding making the full switch to lua/fennel. My init.vim is "only" 220 lines but I'm still lazy

Do you happen to know what this means offhand: `WhichKey: Your <leader> key for "n" mode in buf 0 is currently mapped to ":<C-U>WhichKey ' '<CR>" . WhichKey automatically creates triggers, so please remove the mapping `

Oh wait, I think that's some config from the old plugin.

Yep. Well, seems to have been a smooth transition. Fingers crossed.

Now, I need to convince vim-sexp and vim-sexp-mappings-for-regular-people to pretty up their Which Key descriptions because I do find the new descriptions nicer for sure

Oooh, I was having the same problem @U9J50BY4C with which-key. Just didn't get round to investigating it further. Now on the new lua one and updated develop on conjure. All working a charm!

thanks!

You can always add your own descriptions to mappings, that's what I do (after making a PR for it to be supported by the plugin :))