nvim-surround icon indicating copy to clipboard operation
nvim-surround copied to clipboard

Replay macro when `ys` was run with motion like `t` or `f`

Open dajoha opened this issue 1 year ago • 6 comments

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.

dajoha avatar Oct 03 '23 09:10 dajoha

Notes:

  • Able to replicate
  • Seems to work properly with recording ysiw) or ys$) in the macro

Should probably try to figure out what <80> and <fd> refer to.

kylechui avatar Oct 03 '23 20:10 kylechui

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"

dajoha avatar Oct 04 '23 06:10 dajoha

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.

kylechui avatar Oct 04 '23 22:10 kylechui

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

zdcthomas avatar Apr 25 '24 18:04 zdcthomas

I personally haven't looked into it since the last message; if you do find anything please share 👀

kylechui avatar Apr 25 '24 19:04 kylechui

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.

kylechui avatar May 02 '24 04:05 kylechui

It seems like this issue has just magically disappeared for me on v0.10.0? Can anyone do me a favor and double-check?

kylechui avatar May 30 '24 19:05 kylechui

I was about to say the same thing (honestly kinda spooky I was just about to comment, haha)

zdcthomas avatar May 30 '24 20:05 zdcthomas

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

kylechui avatar May 30 '24 22:05 kylechui