None of the 'Normal mode' binding works or even appears (using which-key)

[Paiusco]

Checklist

• Have you tried updating the plugin to the latest version?
• Have you checked the Breaking Changes issue?
• Have you read through :h nvim-surround to see if there might be any relevant information there?

Neovim Version

NVIM v0.10.2
Build type: RelWithDebInfo
LuaJIT 2.1.1727870382

Plugin Version

Tagged (Stable)

Minimal Configuration

-- (Exaclty what I copied from the README)

{
    "kylechui/nvim-surround",
    version = "*", -- Use for stability; omit to use `main` branch for the latest features
    event = "VeryLazy",
    config = function()
        require("nvim-surround").setup()
    end,
}

Sample Buffer

aaaaaaaaaa
fjrfjrfjrkf efjkefjkefjke
efefef
ff f f f

Keystroke Sequence

ysiw)

Expected behavior

(aaaaaaaaaa)

Actual behavior

w)aaaaaaaaaa

Additional context

I can see it appearing for Visual mode, as expected, but not for Normal mode or Insert mode.

That took me quite some time of re-installing it several times. I can see it loaded from Lazy, and it work for VisualMode, don't know how to get more information for you.
Btw, I've tried with the version = "*" and with that one commented. Both has the same result.

[kylechui]

1. Have you tried it with just nvim-surround installed?
2. Try :verbose nmap ys to see if the keymap is being set, and where

I'm currently updating my Neovim on the bizarre chance that the update broke the plugin It didn't

P.S. I assume you mean the intended behavior is (aaaaaaaaaaa) and not "aaaaaaaaa".

[kylechui]

You should see something like this:

I reckon some other plugin is taking it over, or for some reason the setup function isn't getting called properly (which shouldn't happen, since the plugin does basically nothing on start).

[Paiusco]

Yeah, that's exactly what I see.

Just found out that if I press ys very quick, it seems to be picked up, even though which-key will still think/show that I only pressed y. (same behaviour for ds)

Seems like the bug is on the speed the keys has to be pressed together. If I press them slowly (enough for which-key to appear), then it doesn't work.

NOTE: I'm mentioning whick-key as an example, I don't think it's nothing related to it.

(updated the example with correct expected behaviour)

[kylechui]

Do you have :h timeoutlen set really low? That will cause Neovim to parse longer streams of characters (e.g. ys, yss, cs, ds) as individual chars. For example, ys will get parsed as yank s (which doesn't mean anything).

If it is set to the default, please uninstall all other plugins/disable all other configuration and see if the problem is reproducible.

[Paiusco]

It was set to 300, but even if I comment it out, which-key won't show it ever, and if I press it too fast, then it works but never shown. As I mentioned before.

Funny that the visual works just fine. Maybe I'd need to change the key binds?

[kylechui]

I can't imagine the keymaps themselves are the issue; with the information you've provided I'm not sure what the root cause would be. My guess is that it is most likely config-related, and I would recommend bisecting your config to find the issue

[Paiusco]

Have you ever tried to make sure surround works with which-key? Maybe it's something on their side... weirdly only with surround.

I've disabled everything besides lazy, surround, which-key and I still got nothing related to surround when I press y and wait to see what it shows as possible options

[kylechui]

I think it probably has to do with the fact that due to implementation reasons, all of the keymaps actually return g@ as an expression to be evaluated by Neovim, so which-key is probably trying to "complete" g@ instead of y. If you type ys, you should see a g@ show up in the bottom right. This is necessary for dot-repeating, and is something that I don't see changing anytime soon.

If you wait too long for timeoutlen to hit, then it probably just assumes you want to yank instead, and doesn't consider ys as a valid operation(?) I'm not entirely sure how which-key works, and have never used it before.

[kylechui]

You might find this Reddit post helpful.

[maxcountryman]

I think I'm running into this as well, using lazy + which-key.

What I notice is that if I'm fast enough (i.e. which-key does not trigger its menu display) then this plugin seems to be working as expected.

That said, I would be nice if these keymaps also appeared in the which-key UI.

[NobbZ]

The higher I set vim.o.timeoutlen the easier it becomes to get into surround mode. With the culprit that which-key now has to be waited for much longer…

[chrisgrieser]

This appears to be a bad interaction with whichkey, which apparently does not deal correctly with sequence-mappings for normal mode, and operator + textobject mappings sharing a prefix. It is not limited to this plugin, but also happens when you have a mapping for things like duh, where slowly typing d and then uh also does not work. So I assume the culprit here is whichkey. I have written in more detail over at which-key:

folke/which-key.nvim#907

[folke]

It does deal correctly with operator pending mode mappings.
When you press d, then after timeoutlen expires, you enter operator pending mode.
Exactly the same as without which-key.