targets.vim causing issue with macros about targets.vim

[ggandor]

A totally wild guess, maybe a misfire, but we've had a similar issue here: skimming the codebase, I see that feedkeys is indeed called in a bunch of places, maybe it would worth trying to add the i flag to the calls (see the link).

[ggandor]

Wait a minute, actually, I cannot reproduce this (both vanilla Vim and Nvim 0.5.0 execute the macro correctly).

[deto]

That's strange - I just tried and verified it on a different machine with nvim 0.5.0

How are you recording the macro? I think I wasn't precise enough when I specified it, when I run :reg it really looks like:

Macro: eldf(i: [^[^

Where the is represented by the ^[ character. But this looks confusing since the ^[ is nestled inside of another ^[!

I was able to replicate it again by just recording the macro from scratch, then un-doing, then trying to replay (seeing that it didn't work). Then re-running nvim with -u NONE to skip the config file and replaying the (already saved) macro.

[ggandor]

Recorded the macro, checked :reg, it's eldf(i: [^[^ indeed, replayed on the original line, but works flawlessly, with targets.vim active... Mysterious :)

Edit: Now I could reproduce this, but with targets.vim disabled (not in -u NONE mode though)! This seems totally random, I have no clue at all.

[wellle]

Hey, sorry for taking so long before having a look at this!

I managed to reproduce this issue consistently with Vim (version 8.2.3175).

I tried using feedkeys() with i, but that didn't work.

I found that in the macro, the omap i was being triggered. This is surprising because i in the macro is not being used in an operator pending mode, but should just be used in normal mode.

I wrote a small script to reproduce the issue without targets.vim:

" colorscheme: ["9"='#371377')
" colorscheme = c("9"='#371377')
" colorscheme = c("9"='#371377')

let s:n = 1

function! MyI()
    echom 'MyI' s:n mode(1) v:operator
    let s:n += 1
    return 'i'
endfunction

omap <expr> i MyI()

Put this in a file called repro.vim and then invoke vim like this:

vim --noplugin -u repro.vim repro.vim

Then you can record the macro on line 2 and run it on line 3. (To record the macro type qqeldf(i: [<Esc>q)

I managed to reproduce the issue with this approach in Vim version 8.2.3175.
In Neovim version 0.5.1 I couldn't reproduce the issue (the macro worked as expected).
Then I upgraded Vim to version 8.2.3450 and also couldn't reproduce it anymore.

However, now when I try the original issue (with targets.vim) with my upgraded Vim version 8.2.3450 I can still reproduce the problem. So there must be something else at play here which isn't currently being reflected in my repro script. I will dig into this some more later.

[ColinKennedy]

This is still a bug, unfortunately.

NVIM 0.9.0

reproduction file

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",
        "--single-branch",
        "https://github.com/folke/lazy.nvim.git",
        lazypath,
    })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
    "wellle/targets.vim",
}
require("lazy").setup(
    plugins,
    {
        root = root .. "/plugins",
    }
)

Open a file that looks like this

repro.py

def serialize(self):
    return {
        self._in_use = vendor,
        self._vendor = vendor,
        self._path = path,
    }

I was trying to change lines from self._path = path, to "path": self._path, using a macro like
^f.llyt I"pa": <ESC>Ea,<ESC>lD
then re-running the macro on one of the other lines. The GIFs below show the results

With no plugins (no targets.vim)

With the repro file

I've used this plugin for years so it's not that big a deal but it is a bit of a bummer. It'd be awesome if there was a workaround while a fix is made later but I couldn't find one, myself