[vim/vim] Funny characters happen on gnome-terminal/mate-terminal starting from v9.0.0980 (Issue #11728)

antarestrue

unread,

Dec 19, 2022, 8:16:33 AM12/19/22

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 19, 2022, 12:33:02 PM12/19/22

to vim/vim, Subscribed

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:

:set t_RK=

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Dec 19, 2022, 5:03:35 PM12/19/22

to vim/vim, Subscribed

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?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

antarestrue

unread,

Dec 19, 2022, 8:24:05 PM12/19/22

to vim/vim, Subscribed

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.

I start gnome-terminal simply by typing gnome-terminal on console, and start vim by typing src/vim, which is the build folder. $TERM is xterm-256color. Tried letting $TERM=xterm and does not make difference. My shell is tcsh, but bash is the same. The desktop is Mate Desktop.

Using :set t_RK= can remove the char sequence, but putting this line in .vimrc has no effect, unfortunately. I think it is still related to t_RK and also related to VTE.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Dec 20, 2022, 6:54:01 AM12/20/22

to vim/vim, Subscribed

> 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.
>
> I start gnome-terminal simply by typing `gnome-terminal` on console,

> and start vim by typing `src/vim`, which is the build folder. `$TERM`
> is `xterm-256color`. Tried letting `$TERM=xterm` and does not make
> difference. My shell is `tcsh`, but `bash` is the same. The desktop

> is Mate Desktop.
>
> Using `:set t_RK=` can remove the char sequence, but putting this line
> in `.vimrc` has no effect, unfortunately. I think it is still related
> to t_RK and also related to VTE.
>

> ![image](https://user-images.githubusercontent.com/4499366/208557522-b322a2db-1a53-4771-9371-d20af23749ce.png)

I tried reproducing but I do not see this problem. It might be that an
older version of gnome-terminal could not handle the escape sequence.

My "gnome-terminal --version" output;
# GNOME Terminal 3.44.0 using VTE 0.68.0 +BIDI +GNUTLS +ICU +SYSTEMD

--
Individualists unite!

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 20, 2022, 7:32:11 AM12/20/22

to vim/vim, Subscribed

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. @ antarestrue would it be possible to test a newer version of gnome-terminal? 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_xterm in my vimrc (I forgot why) which also works around/fixes that problem.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 20, 2022, 9:50:42 AM12/20/22

to vim/vim, Subscribed

you can check the vte version via VTE_VERSION var, as i knew the new version of vte based terminal looks just ignore mok esc chars, so then stray chars suspend, that's a knew issue, or solution (upgrade vte).

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

antarestrue

unread,

Dec 20, 2022, 10:56:11 AM12/20/22

to vim/vim, Subscribed

I don't own the machine so I cannot upgrade the system VTE (which is 0.52.2). set t_RK= in .vimrc has no effect somehow. I need to use :set t_RK= every time after opening a file, which is not so good. set term=builtin_xterm does 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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 20, 2022, 11:00:50 AM12/20/22

to vim/vim, Subscribed

After startup, try :verbose set t_RK? to find out where it was last set.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

antarestrue

unread,

Dec 20, 2022, 11:05:55 AM12/20/22

to vim/vim, Subscribed

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 matter set t_RK= is there or not. The code is �[>4;m, seems different than t_RK.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

antarestrue

unread,

Dec 20, 2022, 11:11:23 AM12/20/22

to vim/vim, Subscribed

:verbose set t_RK?

In v9.0.0980, it shows E846: Key code not set: t_RK?. In latest vim, it shows set from ~/.vimrc

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 20, 2022, 11:13:50 AM12/20/22

to vim/vim, Subscribed

VTE just helped to ignore, but it was Not VTE caused it. FYI anyway, IMO.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

antarestrue

unread,

Dec 20, 2022, 11:26:58 AM12/20/22

to vim/vim, Subscribed

I found �[>4;m is t_TE. So, I have a workaround now. Using latest vim 9.0.1083, add both set t_RK= and set t_TE= in .vimrc. Not sure if there is any side-effect, though.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 20, 2022, 12:12:22 PM12/20/22

to vim/vim, Subscribed

You can see using :h t_TE what it is about.

let me close it, since it looks like an issue with an old VTE version.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Dec 20, 2022, 12:12:24 PM12/20/22

to vim/vim, Subscribed

Closed #11728 as completed.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

antarestrue

unread,

Dec 20, 2022, 12:13:49 PM12/20/22

to vim/vim, Subscribed

Okay thanks for help!

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Dec 20, 2022, 12:30:58 PM12/20/22

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

antarestrue

unread,

Dec 20, 2022, 8:25:52 PM12/20/22

to vim/vim, Subscribed

I tried set keyprotocol= and set keyprotocol=xterm:none but that doesn't make difference, still seeing the key code on the screen.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Shane-XB-Qian

unread,

Dec 20, 2022, 8:28:53 PM12/20/22

to vim/vim, Subscribed

let &term=&term, the doc said it take effect after term changed.
// though i am not sure set keyprotocol= and set keyprotocol=xterm:none which one better or equal.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

antarestrue

unread,

Dec 20, 2022, 8:31:52 PM12/20/22

to vim/vim, Subscribed

It works adding let &term=&term after set keyprotocol=, thanks!

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Dude

unread,

Jun 12, 2023, 4:37:19 PM6/12/23

to vim/vim, Subscribed

set t_RK= and set t_TE

This worked; I've tried EVERYTHING. Thank you!!

This fixed systems with VTE_VERSION=5202, and none at all!

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Lucas Szybalski

unread,

Apr 26, 2025, 12:01:50 PM4/26/25

to vim/vim, Subscribed

mrinterestfull left a comment (vim/vim#11728)

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

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Apr 26, 2025, 2:18:23 PM4/26/25

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#11728)

It's a bug in your terminal emulator, not in Vim.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Lucas Szybalski

unread,

Apr 30, 2025, 10:52:22 PM4/30/25

to vim/vim, Subscribed

mrinterestfull left a comment (vim/vim#11728)

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?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

antarestrue

unread,

May 1, 2025, 12:11:42 AM5/1/25

to vim/vim, Subscribed

antarestrue left a comment (vim/vim#11728)

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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

May 1, 2025, 2:18:35 AM5/1/25

to vim/vim, Subscribed

chrisbra left a comment (vim/vim#11728)

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 am not sure why you are asking all those vte 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.