Latest commit seems to be causing stray text to appear on the first line

[riv20]

The latest commit seems to be causing the string ^[[?12;4$y to appear "on top of" the first line of the first buffer I open (screenshot attached). It disappears when I start moving around in the buffer.

Looks like part of a regex? Anyway, I reverted to a previous commit and the issue did indeed go away so I assume this is to do with the latest commit.

I'm using vim 8.1.

Many thanks.

[airblade]

That's weird. It almost looks like an escape sequence.

And this happens when you open a file but before you do anything in the buffer? Does it always happen?

Please could you confirm the SHA of the latest commit you have installed?

Also, please could you enable logging with let g:gitgutter_log = 1, reproduce the error, then post the log file which you'll find in the directory where you have gitgutter installed? Thanks.

[airblade]

Can you reproduce this with vim-gitgutter as your only plugin?

[riv20]

Hi, sorry for the late reply. Attached is the content of the log.

I just tried various combinations of plugins and narrowed it down to one incompatibility: Fastfold. Which is... weird.
gitgutter.log

Currently install SHA is a765079.

Many thanks

[riv20]

Addendum: I can't really reproduce the bug consistently, since it appears only for certain files. Also in all probability it's not inherently caused by vim-gitgutter. So I'll probably close this issue soon.

[airblade]

Thanks for the log file; sometimes weird diff output can explain what's wrong, but here everything looks good.

Thanks for confirming the SHA too. There have been a few occasions in the past where a plugin manager hasn't actually updated a user's gitgutter installation, even though it looks like it has.

I can't see why Fastfold would conflict with gitgutter. As you say, it's weird.

[psliwka]

Affects me too:

For me, gitgutter seems to conflict with tpope/vim-sleuth (these are the only two plugins needed to trigger the bug).

The gitgutter.log after opening and closing single file:

==== start log session ====

  0.000007 function <SNR>14_on_bufenter[5]..gitgutter#process_buffer[12]..<SNR>38_setup_path[7]..gitgutter#utility#set_repo_path[12]..gitgutter#async#execute[1]:
  0.000007 [async] cd /home/psliwka/.homesick/repos/private-dotfiles/home && git  ls-files --error-unmatch --full-name -z -- .vimrc

  0.027547 function <SNR>39_on_exit_vim[11]..1[5]..gitgutter#process_buffer[21]..gitgutter#diff#run_diff[83]..gitgutter#async#execute[1]:
  0.027547 [async] cd /home/psliwka/.homesick/repos/private-dotfiles/home && (git  --no-pager show :home/.vimrc > /tmp/vOWRE5L/1.1.1 && git  --no-pager  -c "diff.autorefreshindex=0" -c "diff.noprefix=false" -c "core.safecrlf=false" diff --no-ext-diff --no-color -U0  -- /tmp/vOWRE5L/1.1.1 /tmp/vOWRE5L/2.1.1 | grep '^@@ ' || exit 0)

  0.032714 function <SNR>39_on_exit_vim[11]..gitgutter#diff#handler[1]:
  0.032714 @@ -0,0 +1 @@
@@ -3,2 +4,2 @@ call plug#begin('~/.vim/plugged')
@@ -6,6 +7,6 @@ Plug 'tpope/vim-sleuth'
@@ -14,2 +15,2 @@ Plug 'airblade/vim-gitgutter'

The garbled line goes away when I repaint the screen with ^L.

I'm currently on gitgutter dc3c0dc, vim 8.1, and git 2.20.1.

[airblade]

I installed vim-sleuth and opened and edited my vimrc; I can't reproduce the problem.

It looks like some kind of terminal rendering glitch to me. I don't know how to debug this any further.

[psliwka]

I can indeed reproduce the problem only on libvte-based terminals (gnome-terminal, xfce4-terminal, lxterminal and friends). There are no glitches on f.ex. xterm and urxvt.

@raphael-vock, @airblade: would you be so kind and verify that hypothesis on your side?

[blueyed]

Are you using Vim or Neovim? Might be worth checking with the other then.

[psliwka]

Yup, it's working fine for me with nvim v0.3.4.

[kodemeister]

Ran into this issue as well. It happens only in terminal Vim and only in certain terminal emulators. xterm works fine but kitty does not. GVim and Neovim seem unaffected.

The bug first appears in 064a3d6. Reverting to previous commit 50932df fixes it for me.

I've managed to reproduce the issue with minimal vimrc including only vim-gitgutter:

call plug#begin('~/.vim/plugged')
Plug 'airblade/vim-gitgutter'
call plug#end()
colorscheme default

The result of opening this vimrc itself in vim:

If I remove colorscheme default then Vim works well. Strange. Looks like vim-gitgutter triggers some weird rendering/timing issues.

[airblade]

@kodemeister Thanks for the information.

The main change 064a3d6 made was to remove a sleep call when you first open a file. I would have expected that to reduce the chance of a weird rendering/timing problem, not increase it.

I have the impression that Vim's colorscheme implementation is quite quirky, and I assume the terminal interface stuff must be fiddly too. I'm surprised that strange rendering bugs don't happen more often – but I can't see why that commit would introduce such a bug.

[riv20]

Hi,
I think it makes sense to reopen the issue since others are experiencing the same thing

[kodemeister]

@airblade Yeah, this is strange. I also found that:

• The issue happens only during vim initialization. That is, a garbled text appears only if I open a file from shell, e.g. vim file.txt. But if I run an empty vim and then open the same file via :e file.txt, everything works fine.
• The issue happens when g:gitgutter_async is set to 1 (the default). Setting it to 0 seems to fix the problem.

I suspect the async gitgutter#utility#set_repo_path somehow conflicts with vim initialization. At least, this crude patch fixes the problem for me:

diff --git a/autoload/gitgutter/utility.vim b/autoload/gitgutter/utility.vim
index 35ff542..3f533ba 100644
--- a/autoload/gitgutter/utility.vim
+++ b/autoload/gitgutter/utility.vim
@@ -147,7 +147,7 @@ function! gitgutter#utility#set_repo_path(bufnr, continuation) abort
   call gitgutter#utility#setbufvar(a:bufnr, 'path', -1)
   let cmd = gitgutter#utility#cd_cmd(a:bufnr, g:gitgutter_git_executable.' '.g:gitgutter_git_args.' ls-files --error-unmatch --full-name -z -- '.gitgutter#utility#shellescape(s:filename(a:bufnr)))
 
-  if g:gitgutter_async && gitgutter#async#available()
+  if g:gitgutter_async && gitgutter#async#available() && !has('vim_starting')
     let handler = copy(s:set_path_handler)
     let handler.continuation = a:continuation
     call gitgutter#async#execute(cmd, a:bufnr, handler)

[airblade]

@kodemeister Thank you for all that, especially the patch. It certainly seems that running an async job at startup causes these rendering problems.

@siegfried-bosch @psliwka Does the patch fix it for you?

[psliwka]

Sorry @airblade, for some reason I can not reproduce the issue anymore, so I am unfortunately unable to test the patch.

[psliwka]

Update: managed to trigger the bug on different file now. The patch indeed fixes the issue for me.

[airblade]

Thanks, everyone, for your help with identifying and fixing this problem.

[chunchengwei]

I meet the same problem "string ^[[?12;4$y to appear "on top of" the first line".
For me, it only appears when I open files like ".cpp" ,".py".
I have installed the plugin "scrooloose/syntastic". when I close this plugin, the problem disappears. I don't know why.

[jward7]

Also seeing string ^[[?12;4$y appearing on top of the first line after updating plugins using vim-plug.
It only appears for empty files. Not really getting in the way of editing, so leaving it for now but monitoring this issue.
I am using the latest iTerm2 version.

[blueyed]

What terminal code refers this to? I only see cvvis=\E[?12;25h in infocmp for myself.
It might come from git maybe?
You could check with strace, e.g. run Vim/Neovim with strace -f -o /tmp/O -s 5000 vim …, and then check the log once it shows up.

[airblade]

I have installed the plugin "scrooloose/syntastic". when I close this plugin, the problem disappears.

@chunchengwei Which is "this" plugin: syntastic or gitgutter?

[airblade]

It only appears for empty files.

@jward7 Empty files which are staged or only in the working tree?

[chunchengwei]

I have installed the plugin "scrooloose/syntastic". when I close this plugin, the problem disappears.

@chunchengwei Which is "this" plugin: syntastic or gitgutter?

@airblade syntastic

[airblade]

@chunchengwei Try let g:syntastic_check_on_open = 0.

Source: vim-syntastic/syntastic#2238 (comment)

I'm confident this problem isn't due to gitgutter; it's a bug somewhere in the terminal and/or vim. See here for some suggestions about where to look for help.

[teleological]

Not to reopen this issue, but for the benefit of others who might end up here searching on terminal control sequence ^[[?12;4$y:

This may be related to limitations in some terminal applications. I have reproduced in iTerm2 3.4.16 but have not seen the issue in Terminal 2.12.7. iTerm2 reports as VT100 (^[[>0;95;0c) when Vim queries it via ^[[>c; Terminal reports as VT220 (^[[>1;95;0c). Disabling the relevant terminal query (set t_RV=) appears to fix the issue for iTerm2. It also appears to be fixed in the nightly built of iTerm2 (e.g. 3.5.20220924-nightly) which responds to the query with ^[[>41;2500;0, i.e. VT420.

[airblade]

It's a vim problem: tpope/vim-rails#579 (comment).