nvim-surround
nvim-surround copied to clipboard
Replay macro when `ys` was run with motion like `t` or `f`
Checklist
- [X] Have you tried updating the plugin to the latest version?
- [X] Have you checked the Breaking Changes issue?
- [X] Have you read through
:h nvim-surround
to see if there might be any relevant information there?
Neovim Version
NVIM v0.9.2
Plugin Version
Tagged (Stable)
Minimal Configuration
use {
'kylechui/nvim-surround',
config = function ()
require('nvim-surround').setup {}
end
}
Sample Buffer
one,
two,
three,
Keystroke Sequence
Record this macro on line 1 : qa0yst,)
Then replay it on line 2: @a
Expected behavior
(one),
(two),
three,
Actual behavior
(one),
<80><fd>atwo<80><fd>a,
three,
(Chars between <
and >
are special characters)
Additional context
Motions which seem to be impacted are t
, f
, T
, F
(followed by any character).
After recording the macro: :echo @a
shows 0yst,<80><fd>a)
, but running :let @a = "0yst,)"
does not fix the problem.
Notes:
- Able to replicate
- Seems to work properly with recording
ysiw)
orys$)
in the macro
Should probably try to figure out what <80>
and <fd>
refer to.
It appears there is a similar problem with https://github.com/tpope/vim-surround, so maybe it's more a limitation of NeoVim and/or Vim than a bug from nvim-surround.
It seems that the sequence <80><fd>a
is defined here https://github.com/neovim/neovim/blob/release-0.9/src/nvim/keycodes.h:
/// K_SPECIAL is the first byte of a special key code and is always followed by
/// two bytes.
/// The second byte can have any value. ASCII is used for normal termcap
/// entries, 0x80 and higher for special keys, see below.
/// The third byte is guaranteed to be between 0x02 and 0x7f.
#define K_SPECIAL (0x80)
// ...
/// KS_EXTRA is used for keys that have no termcap name
/// K_SPECIAL KS_EXTRA KE_xxx
#define KS_EXTRA 253
// ...
KE_NOP = 97, // no-op: does nothing
So this sequence would mean "no-op"
I see, so the keycode that's getting inputted is doing something like K_SPECIAL -> KS_EXTRA -> KE_NOP
. This doesn't seem to happen with other custom operators like gc
from Comment.nvim; I'm not sure if this is an upstream issue or something that both (n)?vim-surround
happened to mess up.
I'm seeing this issue as well, is there any progress on understanding or any fixes anyone has found? I haven't dug much into myself but I'd like to
I personally haven't looked into it since the last message; if you do find anything please share 👀
Hmm it seems related to this upstream issue (I was able to recreate the issue by running qa0yst,)
and then :put a
), but I'm not sure what the solution here would be.
It seems like this issue has just magically disappeared for me on v0.10.0? Can anyone do me a favor and double-check?
I was about to say the same thing (honestly kinda spooky I was just about to comment, haha)
I was procrastinating on doing my homework so I just figured I'd go back through all the issues and check in :laughing: I'll mark this as resolved but anyone can feel free to ping me if anything changes