3

Recently, on Debian Sid (accessed via SSH from an ArchLinux machine using Terminator), something has started triggering the [I / :ilist function whenever vim gains focus. If I start vim without arguments I get E349: No identifier under cursor.

Nothing in the au BufEnter list looks relevant, and au FocusGained is empty. I have no vimrc in my home folder, and the only line in vimrc.local was set ttymouse=. In the comments, it was discovered that set ttymouse= is necessary to reproduce the problem.

vim --version is 8.2 installed from the official sid package. My $TERM is xterm-256color. The ability to detect terminal focus was introduced in patch 2345, so only systems with fairly recent vim packages are able to reproduce.

For now, I'm avoiding the problem by adding set t_fd= and set t_fe= in the system's vimrc.local (as suggested by :help focus), but I'd like to figure out what's actually causing it. What's doing this and how can I turn it off?

It does not reproduce inside vim --clean unless I manually run :set ttymouse=

Improve this question
11
  • 1
    You can also try vim --clean to see if the problem still happens when you don't have any vimrc or plug-ins loaded... (Including the system-wide vimrc shipped by Debian.) It would be nice to check whether that makes a difference or not...
    – filbranden ♦
    Jan 28, 2021 at 23:53
  • 1
    @filbranden Edited question to clarify. Also vim --clean is a fantastic thing I didn't know existed.
    – Dan
    Jan 29, 2021 at 0:08
  • 1
    See line 2066 in src/term.c in that patch, that should explain the [I. I'm betting what's happening is that your Terminator doesn't recognize those special sequences... Can you try it under actual xterm or something like urxvt or gnome-terminal?
    – filbranden ♦
    Jan 29, 2021 at 0:27
  • 1
    @filbranden It reproduces under xterm but not urxvt... i note that the line you linked in the source code is gated by if (use_xterm_like_mouse(term)) and if i remove set ttymouse= from vimrc.local the problem goes away
    – Dan
    Jan 29, 2021 at 0:33
  • 3
    I think the problem is that XTerm sends different escape codes than Vim is expecting No, those are 2 different sets of sequences. The first set toggles the feature on and off. The second set tells Vim which sequences the terminal will send when the window gains the focus or loses it, so that Vim knows FocusGained or FocusLost should be fired. Relevant issue: github.com/vim/vim/issues/7755
    – user938271
    Jan 29, 2021 at 11:36

1 Answer 1

Reset to default
3

This appears to be a genuine bug in vim, which was fixed by the patch 8.2.2428. Both the Arch and Debian packages have now been updated to include this patch, so pacman -Syu or apt-get upgrade (respectively) will fix the problem.

The escape sequence terminal emulators send when they gain focus is \<Esc>[I. When the ttymouse vim option has been cleared, even though vim sends the terminal \<Esc>[?1004h to indicate it supports focus events, it fails to recognize the \<Esc>[I it receives in response.

Instead, it behaves as it would if I had literally pressed Escape, followed by [I, and tries to launch the identifier list.

Workarounds include setting a $TERM that doesn't support focus events (e.g. TERM=st-256color), enabling ttymouse, or disabling focus events in vimrc with set t_fd= t_fe=.

Credit to @filbranden, @martin-tournoij, and @user938271 for finding this answer in the question comments.

Improve this answer
1
  • Thanks for posting a summary as answer here! :-)
    – filbranden ♦
    Jan 29, 2021 at 17:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.