Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

targets.vim causing issue with macros #268

Open
deto opened this issue Jul 23, 2021 · 6 comments
Open

targets.vim causing issue with macros #268

deto opened this issue Jul 23, 2021 · 6 comments

Comments

@deto
Copy link

deto commented Jul 23, 2021

I'm having an issue where enabling targets.vim is causing unpredictable behavior in macros when replaying them.

I tried to create a minimal example here:

For this file:

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

Where the cursor is at the start of the second line - I have a macro that should make this line look like the first line:

Macro: eldf(i: [<ESC>^

However, it results in the second line looking like:

colorscheme"9"='#371377')

Here is my vimrc:

"Change leader key to space
let mapleader = "\<Space>"

" Vim Plug
call plug#begin()

" Better text targets
Plug 'wellle/targets.vim'

call plug#end()

The macro works as intended if I comment out the Plug 'wellle/targets.vim' line, and applies incorrectly if I leave that in.

I am running neovim v0.4.3 on Ubuntu 18.04. I'm on commit 8d6ff298 of targets.vim

@ggandor
Copy link

ggandor commented Jul 23, 2021

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
Copy link

ggandor commented Jul 23, 2021

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

@deto
Copy link
Author

deto commented Jul 23, 2021

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
Copy link

ggandor commented Jul 23, 2021

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
Copy link
Owner

wellle commented Sep 30, 2021

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
Copy link

ColinKennedy commented Apr 25, 2023

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)

working

With the repro file

broken

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants