0

I am trying to access vi editor using Xquartz on a remote server using Mac computer. Remote server uses Linux

Problem I am facing is that, if I try to open a file, previous file/command history start to mess up with the display. To be clear, it is not messing up with the contents of the file - but just the display. I am attaching a snapshot below

enter image description here

The file actually contains only those things which are in black. The @/C^ etc in blue are from a file previously opened (and closed thereafter) and the others in red are also from command history.

After going through some of the previous posts, some suggested using reset commands shopt | grep checkwinsize. I tried shopt | grep checkwinsize and it is showing checkwinsize on. Now I am out of options. Please let me know if you need any further details

Edit: echo $TERM : xterm-color

enter image description here

Vaidyanathan
  • 379
  • 3
  • 6
  • 16
  • The question doesn't mention the value of `TERM` (nor the output of `infocmp`). Both are needed to show if it's simply a problem with the terminal emulator. If you are also using `screen` or `tmux`, those also (besides `vim`) can get confused about what's actually shown on the terminal. – Thomas Dickey Oct 25 '17 at 08:22
  • I am not very familiar with this. As per your suggestion, I have added both $TERM and infocmp – Vaidyanathan Oct 25 '17 at 16:04

2 Answers2

0

Actually that's vim, not vi (the last line on the screen demonstrates that).

Considering that most of the unwanted text would be left in the alternate screen, it seems that you're using a terminal description which supplies empty strings for the smcup and rmcup for switching to/from the alternate screen.

Part of that features clears the screen when switching to the alternate screen, and vim's not clearing the screen on its own (unless you press controlL, for instance, to repaint the screen).

Since people frequently advise editing the terminal description to remove those capabilities, vim's likely to deal with that "as expected", so I'd expect something unusual such as empty strings, e.g.,

smcup=,rmcup=,

in the output of infocmp. It's unnecessary (and has been for twenty years) with xterm. See the xterm FAQ Why doesn't the screen clear when running vi?

In the revised question, the TERM uses xterm-color which (see the FAQ What $TERM should I use?) is not really recommended (xterm-xfree86 or xterm-new are preferred). But vim should cope with that (it works on my machine, going from xterm #326 on OSX to Debian 7). However, in a quick check using vim to edit /bin/sh for example, and exiting, it shows some (lesser) confusion about how to clear the screen, leaving some debris.

The distinction between xterm-color and xterm-new is that in the latter, vim (should) see that it is able to clear the screen more readily. In the former, it has to overwrite areas on the screen, and if it became confused (such as with a difference in locale vs the terminal settings) about what shows on the screen, then it will leave noticeable debris.

You can see if xterm is using UTF-8 encoding by the presence of a check-mark on the (control-right mouse menu) UTF-8 Encoding menu entry. If that is not set, and the locale on the remote server uses UTF-8, then you can get interesting (and surprising) behavior. Just type

locale

on the command-line to see (conventionally the locale variables corresponding to UTF-8 encoding are named with that as a suffix in some way).

Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
  • How to take care of this problem? Ctrl+L did not work - I mean once I open vi/vim editor and scroll down one page, the details (letters/words etc) from the previous page still appears on the new page – Vaidyanathan Oct 24 '17 at 23:56
  • 1
    Control/middle-mouse menu has a "full reset" which might help. But the problem is likely in the terminal description. – Thomas Dickey Oct 25 '17 at 00:32
0

Try, in xterm, pressing [CTRL] right-button (Font Menu). If UTF-8 Encoding is not selected, try doing so.

If that worked, then in your ~/.Xdefaults add:

XTerm.vt100.locale: true
slashlos
  • 913
  • 9
  • 17