Fixing scrolling in nano running in tmux in mate-terminal
Solution 1
From the tmux FAQ:
****************************************************************************** * PLEASE NOTE: most display problems are due to incorrect TERM! Before * * reporting problems make SURE that TERM settings are correct inside and * * outside tmux. * * * * Inside tmux TERM must be "screen" or similar (such as "screen-256color"). * * Don't bother reporting problems where it isn't! * * * * Outside, it must match your terminal: particularly, use "rxvt" for rxvt * * and derivatives. * ******************************************************************************
http://tmux.git.sourceforge.net/git/gitweb.cgi?p=tmux/tmux;a=blob;f=FAQ
Solution 2
I had a very similar problem, but instead of nano I was using vim. I also compiled tmux from source (this detail will be important). I've been pulling my hair out trying to figure out the solution and while I don't know exactly why, I wanted to provide some steps I tried to finally get it working. What my problem was (adapted from original question):
- I open a terminal (in CentOS 7, so gnome-terminal)
- zsh is the shell
- Then I run tmux
- Edit a file with vim
- Split the view in vim with
:sp
- Create a vertically split pane in tmux
- Go back to file, scroll up and down that file with the cursor
- Issue: When scrolling down in either vim viewport, only the very bottom of the viewport gets refreshed (only the line the cursor is on)
- Issue: When scrolling up in either vim viewport, only the very top of the viewport gets refreshed (only the line the cursor is on)
- Sometimes, however, I could get the bottom viewport to scroll properly if I adjusted the zoom of the terminal (
Ctrl-minus
orCtrl-Shift-+
) - Issue: Along with that, if I went to the new tmux pane and type in a bunch of text (with spaces), then went to the beginning of the command and used the delete key to delete some characters, the terminal would print a portion of the command on the very top line as I was still editing. And I wouldn't be able to get an accurate sense of what was actually being typed. No fun.
Here's what I did to eventually fix it: First, I would suggest making sure tmux is using the screen-256color
TERM setting. Put this in your .tmux.conf:
set -g default-terminal "screen-256color"
Now close all of your tmux sessions. Reopen tmux and see if that somehow fixed the problem:
echo $TERM
Should say screen-256color
. Unfortunately that wasn't enough for me, I was getting the same problems.
What ultimately fixed it for me was cloning the latest tmux version (at time of writing, v2.8) from github, then recompiling. I put this new build/binary in a separate directory, and lo and behold the new binary worked while the old one (unknown version) still didn't. The old one was still a pretty recent version, though.
Related videos on Youtube
eoinoc
Updated on September 18, 2022Comments
-
eoinoc over 1 year
The problem:
- I open a terminal (in Linux Mint, so mate-terminal)
- zsh is the shell
- Then I run tmux
- Edit a file with nano
- Scroll up and down that file with the cursor
- Issue: When scrolling down in nano, only the bottom half of the terminal window gets refreshed
- Issue: When scrolling up in nano, only the top half of the terminal windo gets refreshed
The complete nano view of file does not get refreshed in my terminal window when scrolling. Any tips?
Edit: my .tmux.conf
It seems that this line specifically is the culprit (as commenting it out fixes the problem):
set -g default-terminal "xterm-256color"
I'm pretty sure I added that line because I have issues even running nano during an SSH session.
Here is the full file:
set-option -g default-shell /bin/zsh # Make sure tmux knows we're using 256 colours, for # correct colourised output set -g default-terminal "xterm-256color" # The following were marked as "unknown", so # I do know what I'm doing wrong. #set -g mode-mouse on #setw -g mouse-select-window on #setw -g mouse-select-pane on # Attempting to stop "alert" sound upon startup # but none of these are working... set-option bell-on-alert off set-option bell-action none set-option visual-bell off
-
Admin over 11 yearsI have realised that this happens regardless of being in an SSH connection or not. So SSH does not seem to be part of the problem. This brings it down to tmux, or my shell, I'm guessing.
-
Admin over 11 yearsThe shell doesn't matter. SSH was the most likely culprit (an unknown terminal type on the server), but that's not it… What's the value of
TERM
inside tmux (echo $TERM
in the shell inside tmux)? Also, doesecho $LINES
return the correct number of lines? If you have a.tmux.conf
, try without, and if it's the culprit, post its content. -
Admin over 11 yearsThe value of
TERM
isxterm-256color
. Lines says39
(hmm, does that mean columns or rows?). Right you are, moving.tmux.conf
fixes the issue, so I'm putting the contents above. -
Admin over 11 years
tmux
usesscreen-256color
by default. ChangingTERM
to something else withintmux
may have unintended consequences. Make sure the terminfo entry for screen-256color is present on your system. -
Admin over 11 yearsI ended up with the value of
screen
fortmux
, asscreen-256color
ended up with nano failing to launch during SSH sessions with the error:Error opening terminal: xterm-256color
.
-
eoinoc over 11 yearsSet value to
screen
specifically, asscreen-256color
resulted in the errorError opening terminal: xterm-256color
launching nano during SSH sessions. -
Admin over 11 years1+ Lifesaver! Made the switch from
screen
just now and this problem was bugging me big time. -
Robert Bain about 4 yearsSetting the $TERM in my docker containers on Ubuntu 18 resolved this issue for me with nano. Thank you!