Repository navigation
Funny characters happen on gnome-terminal/mate-terminal starting from v9.0.0980 #11728
Description
The upper-left characters (see below). This happens at the cursor position. If you have opened a file and moved the cursor, next time you open the file, this will happen there.
And this only happens on gnome-terminal and mate-terminal, but not konsole nor xterm.
Activity
chrisbra commentedon Dec 19, 2022
I guess this comes from Vim requesting the terminals support for Keyboard protocol and your terminal does not support it.
so try to disable this:
brammool commentedon Dec 19, 2022
Please describe exactly what you did. You say you opened a file, how?
The screenshot actually shows Vim not editing any file.
How did you start gnome-terminal?
What shell are you using?
What is the value of $TERM, or the value of 'term' in Vim?
antarestrue commentedon Dec 20, 2022
The screenshot was showing when not editing a file, the cursor is at the upper-left corner, and the char sequence is at the upper-left corner. If you open a previously opened file, the char sequence can be anywhere at the last position of the cursor (see below). Moving cursor away does not make it disappear. The char sequence stays at its initial position. And it will not be saved to the file.
I start gnome-terminal simply by typing
gnome-terminalon console, and start vim by typingsrc/vim, which is the build folder.$TERMisxterm-256color. Tried letting$TERM=xtermand does not make difference. My shell istcsh, butbashis the same. The desktop is Mate Desktop.Using
:set t_RK=can remove the char sequence, but putting this line in.vimrchas no effect, unfortunately. I think it is still related to t_RK and also related to VTE.brammool commentedon Dec 20, 2022
chrisbra commentedon Dec 20, 2022
I also tried to repduce and couldn't using gnome-terminal from bullseye (3.38.3), buster (3.30.2) and stretch (3.22) and neither shows this error. It may depend on the version of libvte. Ah, I see it, once I downgrade libvte-2.91 (0.62.3, bullseye) to 0.46.1 (stretch). Once I upgrade libvte to 0.54 (buster) it does not show it again.
As mentioned it goes away, if I use
:set t_RK=Alternatively, I have
:set term=builtin_xtermin my vimrc (I forgot why) which also works around/fixes that problem.@antarestrue would it be possible to test a newer version of gnome-terminal? Or test the above mentioned work-arounds please.
Shane-XB-Qian commentedon Dec 20, 2022
antarestrue commentedon Dec 20, 2022
I don't own the machine so I cannot upgrade the system VTE (which is 0.52.2).
set t_RK=in.vimrchas no effect somehow. I need to use:set t_RK=every time after opening a file, which is not so good.set term=builtin_xtermdoes not work and it becomes only black and white...Anyway, now we are sure it is related to VTE and it is fixed in later version of VTE.
chrisbra commentedon Dec 20, 2022
After startup, try
:verbose set t_RK?to find out where it was last set.antarestrue commentedon Dec 20, 2022
I just found an interesting result. With the latest vim 9.0.1083,
set t_RK=works in.vimrc! However, when I close vim, it outputs another character sequence to console right before the prompt, no matterset t_RK=is there or not. The code is�[>4;m, seems different thant_RK.antarestrue commentedon Dec 20, 2022
In v9.0.0980, it shows
E846: Key code not set: t_RK?. In latest vim, it shows set from~/.vimrcShane-XB-Qian commentedon Dec 20, 2022
antarestrue commentedon Dec 20, 2022
I found
�[>4;mist_TE. So, I have a workaround now. Using latest vim 9.0.1083, add bothset t_RK=andset t_TE=in.vimrc. Not sure if there is any side-effect, though.chrisbra commentedon Dec 20, 2022
You can see using
:h t_TEwhat it is about.let me close it, since it looks like an issue with an old VTE version.
antarestrue commentedon Dec 20, 2022
Okay thanks for help!
brammool commentedon Dec 20, 2022
So there is a sequence of things that happen, and a few places that "should work" but don't really work as expected.
The start is setting $TERM to xterm-256color. This makes Vim think this terminal is xterm-compatible. Vim then tries to switch on modifyOtherKeys level 2, so that more keys can be mapped. This probably doesn't work for gnome-terminal, but Vim doesn't know that so sets up t_TI, t_TE and t_RK for when it works. Either way, an xterm-compatible terminal should ignore the codes, even when not supported.
The core of the problem appears to be that this terminal doesn't ignore these codes. This was fixed in a later version, with the fix in libvte, apparently. If you can't upgrade the terminal or libvte you will keep getting these characters.
A way to avoid the problem is making 'keyprotocol' empty. Vim will then not try use modifyOtherKeys, even though the value of $TERM contains "xterm". That should work better than making t_TE and t_RK empty, because those may be set later.
antarestrue commentedon Dec 21, 2022
I tried
set keyprotocol=andset keyprotocol=xterm:nonebut that doesn't make difference, still seeing the key code on the screen.Shane-XB-Qian commentedon Dec 21, 2022
antarestrue commentedon Dec 21, 2022
It works adding
let &term=&termafterset keyprotocol=, thanks!mikeSGman commentedon Jun 12, 2023
This worked; I've tried EVERYTHING. Thank you!!
This fixed systems with VTE_VERSION=5202, and none at all!
mrinterestfull commentedon Apr 26, 2025
Thanks for the workaround solution.
Was the permanent fix checked into a main repo?
The characters are now default Debian Stable. Finally after few months of being annoyed with it I found this thread. It would vim settings should be updated.
Can someone confirm the fix was included with next release. And what version.
Thank you
Lucas
chrisbra commentedon Apr 26, 2025
It's a bug in your terminal emulator, not in Vim.
mrinterestfull commentedon May 1, 2025
Can you elaborate?
a) What is the ticket# for the affected terminal? for debian stable?
b) is it schedule to go into testing release or fixed in backports
c) was this bug accidental, and high priority. It cripples the whole vim ecosystem and renders it nu-usable for majority of new vim users?
antarestrue commentedon May 1, 2025
I would not say it is a bug in either vim or vte, IMO. The new vim uses a feature that the old vte does not support. So, the problem is more like that Debian packager should not upgrade vim until they upgrade vte.
chrisbra commentedon May 1, 2025
Please read the ticket carefully again. The bug is in Libvte, but already fixed in a later version. With that information you can go to debian and ask if they want to package a later Libvte version for stable (I doubt they will, however). I am not sure why you are asking all those vte/Debian related questions in the Vim bug tracker, we don't know those. But you have enough information to find those details at the relevant projects and their issue trackers.
We have documented here in this ticket a workaround to make this bug go away, if you are affected. That is all we can do for you