9

First let me show a screenshot below. enter image description here In the modeline, a strange sequence of characters(>4;m<ESC>[>4;m<ESC) is shown. And not only in the modeline, I have seen such similar sentence in the command line when :wq and in the buffer when I tried to update plugins using :PlugInstall, too.

It's not a buggy problem, but it looks annoying. At the first, I thought it was some mysterious ANSI escape sequences. But when I searched more information about that, I happened to find that it seems the code for t_TE(^[[>4;m) and t_TI(^[[>4;2m). Try :set termcap and you will find them. However, only vim 8.2(it's the version I use) supports these code which is not true for vim 7.4(the default vim installed by ubuntu 16.04).

There're few information about t_TE and t_TI. But to be honest, I'm not curious what they are and how they work. I just want to suspend the display about them. I guess, since these codes are added by new vim, it's probably the same codes are not compatible with gnome-terminal so that it happens. But I dunno and I have very limited knowledge about termcap or terminfo anyway.

Actually I'm new to vim. It really diverts my attention when I catch a glimpes of these strange codes. I appreciate your help.

Update

Thanks for all comments and answers. For completeness, I update more information about where vim works on and terminal related info of mine.

  • My OS is Ubuntu 16.04.7LTS
  • I'm using terminator 1.91, but I also tried on GNOME Terminal 3.20.2 and the same problem happens
  • My $TERM is xterm-256color

Maybe I should also post what my $termcap is but it would be like a spam. But anyway, I don't remember I manually set all term related environment variables, so I believe they are what they are with default, unchanged values.

6
  • 1
    Welcome to Vi&Vim SE. Unfortunately, this looks like something seen before...a tough nut that we haven't yet cracked: Unreadable characters in command section and Quickfix window. (Note: if it's determined that this is the same issue as yours, your question might be closed as a duplicate. Don't let that bother you...it's just how things are done. :)
    – B Layer
    Sep 21, 2020 at 10:21
  • @BLayer Yep. That's exactly the same problem. You can close my post.
    – HQW.ang
    Sep 21, 2020 at 10:31
  • @BLayer That's no problem. But I want to add more information as a comment to the link you gave. But without enough reputation, I can't. Then how?
    – HQW.ang
    Sep 21, 2020 at 10:37
  • (Consolidation of previous comments to reduce clutter.) Sorry, my bad, I forgot we don't dup-close questions unless the earlier one has an answer. I've linked this one to that one in a comment (it was already done automatically due to my first comment but people don't always notice the link in the sidebar). If you have something to add I'd either add it to your question (which you can edit) or as a comment here.
    – B Layer
    Sep 21, 2020 at 10:58
  • What terminal emulator are you running Vim on? And what is your $TERM variable set to? (I'm guessing TERM=xterm but also that you're not on "xterm" but on something else...) Please edit the question to include that information.
    – filbranden
    Sep 21, 2020 at 12:21

1 Answer 1

16

t_TI and t_TE are terminal options. You can set them with sequences which will be sent by Vim to the terminal when the latter is resp. put into "raw" mode, or when it's made to quit "raw" mode.

Since patch 8.1.2134, Vim supports a feature called modifyOtherKeys, provided by xterm:

Problem: Modifier keys are not always recognized.
Solution: Handle key codes generated by xterm with modifyOtherKeys set.
Add this to libvterm so we can debug it.

It lets Vim distinguish various keys, like <C-i> from <Tab> or <M-h> from è, which was impossible before. This is especially useful when you want to install a mapping on some key, without clobbering another one.

The feature was enabled by default in 8.1.2194. Starting from this patch, when Vim thinks it's running in xterm, it automatically sends this sequence to the terminal whenever the latter is put into raw mode:

^[[>4;2m

The syntax of the sequence is documented here:

CSI > Pp ; Pv m

Its purpose is to set or reset key modifier options, which the terminal inspects to decide whether it should construct escape sequences holding information about possible modifiers pressed with a given key.

CSI is ESC [ (aka Control Sequence Introducer). The first parameter Pp is a code which identifies the terminal resource to set or reset. The second parameter Pv is the value you want to assign to the resource.

In your sequence, Pp has been given the value 4, which identifies the modifyOtherKeys resource (there are other resources identified by other codes, such as modifyCursorKeys identified by 1).

Similarly, Pv has been given the value 2, which tells the terminal that the feature should be enabled for all keys, including those with well-known behavior (like Tab).

For more info, see:

That should cover most of what you don't want to know about.

Now:

I just want to suspend the display about them.

If the sequences are merely printed on the terminal, it means the latter doesn't understand them. If it doesn't understand them, it means it's not xterm (or at least it's not fully xterm compatible). There are 2 ways to fix the issue:

  1. tell Vim to disable the modifyOtherKeys feature so that it stops sending those sequences
  2. fix your TERM which is probably xterm or some derivative like xterm-256color

I would go with 2., and stop telling every program running in the terminal that the latter is xterm, when it's really not, but if you prefer 1., just add this into your vimrc:

set t_TI= t_TE=

If you want to go with 2., configure your gnome terminal like this:

  • open the Edit menu in the bar at the top of the window

  • click on the Profile Preferences button in the menu

  • click on the Command tab in the newly opened window

  • write this in the Custom command field:

    /usr/bin/env TERM=gnome-256color /bin/bash
    

Tested on Ubuntu 16.04. I have no idea whether this particular sequence of clicks still works in a recent version of the OS. You might also want to choose another shell than bash, or another path than /bin/bash.

Alternatively, write this in a shell init file:

export TERM=gnome-256color

If you need an updated terminfo description for your terminal, try this:

$ curl -LO http://invisible-island.net/datafiles/current/terminfo.src.gz
$ gunzip terminfo.src.gz
$ tic -sx -e gnome-256color terminfo.src
8
  • 1
    Just note that setting TERM in a shell init file can make that file non-portable to other setups (i move my dotfiles to lots of machines, so i care). One solution is to source « local » files that can make tweaks like this that arent part of a core setup.
    – D. Ben Knoble
    Sep 21, 2020 at 12:26
  • 1
    Just note that setting TERM in a shell init file can make that file non-portable to other setups IMO, that shouldn't even be set in a shell init file; it should be set in a terminal config file. But using a shell init file is a workaround for some people, and sometimes it's not obvious how to configure TERM at the terminal level. I've yet to find out how to do it on my old version of the xfce terminal (actually I've given up).
    – user938271
    Sep 21, 2020 at 12:33
  • It's great that you finally cracked this one! I think your answer is missing two items though: 1) What the title asks: what t_TI and t_TE actually are (or do). Sorry if I missed it, but I don't see an explanation (I didn't follow all the links.) 2) You might want to mention that the support for modifyOtherKeys was introduced in Vim 8.1.2134 (as you mentioned in vi.stackexchange.com/q/26500/18609), that's useful information. Thanks for yet another excellent investigation!
    – filbranden
    Sep 21, 2020 at 13:04
  • Awesome, thanks for the update!
    – filbranden
    Sep 21, 2020 at 15:03
  • @user938271 Thanks a lot! I tested 1. and 2.. Both of them work. But with 2nd method, after changing xterm-256color to gnome-256color, the appearance of terminal looks like distorted. I mean it's not true color and become darker than before. Is this also your case or how can I fix then.
    – HQW.ang
    Sep 22, 2020 at 7:38

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.