I am using terminal from a Mac OS X 10.10 (Yosemite) and SSH’ing into a fedora machine and am having a couple strange issues with the terminal:

  1. When I :q from vim, the contents of the vim screen is still there. When I :q on my mac or even from the actual desktop screen on my Fedora machine, when I :q a vim file, the vim screen disappears and I am returned to the terminal (that is, I am returned to the command prompt where the previous line is simple $vim <whatever_file_I_edited>.txt whereas now, I cannot see the previous line because I still see the contents of the file I was editing via vim.

  2. When I use the scroll up / scroll down feature on the trackpad, it scrolls the previous entries to the terminal, and not the length of the terminal window itself.

How can I fix these issues?


You don't really have "issues" other than that you've become too comfortable with an xterm-ism and incorrectly expect it to be universal.

xterm — and GUI terminal emulators like it such as gnome-terminal, lxterminal, konsole, and so forth — implemements what is known as an "alternate screen buffer". With one control sequence, programs can switch the terminal emulator to displaying and writing to that buffer. With another, they can switch back to the original screen buffer. Programs like vim (and less) issue the first control sequence when they start up/resume, and the second when they shut down/suspend. This gives the effect of restoring the prior screen contents when vim terminates.

This is not a given.

Not all terminals and terminal emulators have an alternate screen buffer. The terminal emulator built into your operating system's kernel does not. If you had run vim on a kernel virtual terminal, you would have seen this very same behaviour. Real terminals generally do not. (Actual DEC VT family terminals, for example, have a mechanism that involves "pages" that isn't the same and that is driven by a different set of control sequences.)

Even if your terminal has one, you must ensure that the termcap/terminfo entry for the current terminal type has the appropriate information, telling TUI programs like nano and Midnight Commander what control sequences to emit for showing and hiding the alternate screen buffer. That's a combination of picking (and setting) an appropriate TERM environment variable value to select an entry from Fedora's termcap/terminfo database that matches the capabilities of your local MacOS 10 terminal emulator, and of perhaps even editing that database.

Exactly what you set TERM to isn't a fixed answer, as it depends from what emulation you have configured MacOS 10's terminal program to provide. For that, you will simply have to look at its settings. If you've told it to emulate xterm in 256 colour mode, then you'll have to pick a terminal type (very likely xterm-256color) that describes that in Fedora's terminfo database.

Further reading

| improve this answer | |
  • Brilliant, I actually went out of my way to specify that the MacOS terminal should use xterm-256color so that I can get nice pretty colors the way that I like them. I will read more about this as you suggested - but can I ask one more simple question? Is it a simple matter of telling Fedora that I want it to recognize / use xterm-256color and then it will automagically work? EDIT: Fedora is actually already using xterm-256color ... Now I'm confused. – drjrm3 Jan 30 '15 at 15:01

For some reason Vim on Mavericks did not come configured with a color scheme. After I added some lines to the vimrc file (copy & paste from a site) it started behaving like you describe, in my case, deleting extra whitespace after each statement fixed it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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