Color scheme is gruvbox.
without tmux:
with tmux:
I tried
set -g default-terminal "screen-256color"
and
set -g default-terminal "tmux-256color"
in .tmux.conf, none worked.
According to this unix.stackexchange post, you should also add this line in your .tmux.conf:
set-option -ga terminal-overrides ",*-256color*:TC"
The accepted answer in the above link already has a good explanation of why this is the case, so I'll just summarize:
default-terminal is the configuration used by the terminals emulated inside tmux. terminal-overrides is the configuration used by tmux to communicate with the actual terminal it's running in (we'll call that the parent terminal). In your case, just setting default-terminal to use "screen256-color" isn't enough because tmux will still communicate with its parent terminal using a limited color set. Additionally setting terminal-overrides to also use "256 color" means that tmux will both use the expanded color set internally, and will tell its parent terminal to render in that expanded color set.
# Tell tmux to use 256-color internally
set -g default-terminal "screen-256color"
# Allow tmux to send 256-color to its "parent terminal", allowing
# the terminal to render colors in full.
set-option -ga terminal-overrides ",*-256color*:TC"
The reason tmux -2 works is because it does essentially the same thing. man tmux contains this description of the -2 flag:
-2 Force tmux to assume the terminal supports 256 colours.
which is essentially what we did when setting terminal-overrides. Assuming the parent terminal supports 256 colors means tmux will send information to be rendered in the 256 color set instead of whatever limited color set it is defaulting to.
Using tmux -2 solves the problem. Anyone knows why?
Try to use the same configuration that #scupit but without the - inside the quotation marks. I mean: set -ga terminal-overrides ",*256col*:Tc"
Related
When I start vim I get:
Error detected while processing /home/kossak/.vimrc:
line 1: E484: Can't open file /tmp/vdf7WFR/0
Press ENTER or type command to continue
My first line in ~/.vimrc is let s:uname = system("uname -s").
The error happens because SHELL env var is set to /home/kossak/.local/bin/xonsh. It is set automatically by tmux, because of set -g default-shell /home/kossak/.local/bin/xonsh in my .tmux.conf. I'd like to manually set $SHELL to /bin/bash, without changing default-shell of tmux. Is it possible?
I know I can run tmux setenv -g SHELL '/bin/bash' in CLI and then new panes will have new value, but how to do it in .tmux.conf, so tmux does it automatically for me?
I tried adding setenv -g SHELL '/bin/bash' to .tmux.conf but it doesn't work (the value of $SHELL is not changed).
Just tell vim to prefer bash, to make your vim consistent.
if executable('bash')
set shell=bash
endif
You can't make tmux swap env-vars around, but you can make xonsh do it pretty easily, e.g.
with ${...}.swap({"SHELL": "/bin/bash"}):
vim
would open vim with your environment mutated to set $SHELL=/bin/bash but only for the body of the context manager.
You could set this as an alias for vim in your xonshrc
def _vim():
with ${...}.swap({"SHELL": "/bin/bash"}):
vim
aliases["vim"] = _vim
How can I get Tmux to detect Vim in current session?
I want to make status-right dissapear when I have Vim open in foreground and reappear otherwise. How do I do this? I'm thinking of using set-hook -g?
You could make the text in status-right conditional on pane_current_command, for example something like:
set -gF #old-status-right '#{status-right}'
set -g status-right '#{?#{==:#{pane_current_command},vim},,#{E:#old-status-right}}'
Look at https://github.com/tmux/tmux/wiki/Formats for syntax.
Referring to this answer I tried increasing the buffer size using commands
set-option -g history-limit 10000
set -g history-limit 10000
but it does not work for me. I want to increase the buffer size of all the windows or at least the current window in tmux. I am opening the tmux session in Putty.
Note: I was trying to use the mouse scroll. I am able to scroll up using "prefix [" but not using the mouse
Some troubleshooting tools that helped me when I had this problem:
yes
to quickly fill up the scrollback
tmux new-session
to make sure I was getting a new session
tmux show-options -g
to see if tmux actually had the right setting.
In my case, I was unknowingly attaching to previous tmux sessions, that were created before I increased the history-limit.
In my case I had some tmux processes running even though tmux a showed no attachable sessions. I manually killed every tmux process and after starting a new session new history-limit finally kicked in (check by tmux show-options -g to make sure).
When I run Vim from inside a tmux session and copy some text to the clipboard, each line gets padded with spaces to the right.
For example, say I have a text file like this:
^some$
^text$
Note: I've used ^ and $ to mark the beginning and end of a line respectively. They are not part of the file content.
I start tmux and open this file in Vim. I press Shift (to prevent Vim from processing the mouse click) and mark the complete text by holding the left mouse button clicked. Then I copy it to the clipboard with Shift+Ctrl+c.
The result in the clipboard is something like:
^some $
^text $
Note the extra spaces. The number of spaces depends on the terminal width.
If I start Vim without tmux or if I just cat the file content and then copy it, there are no extra spaces. So it must have to do with the combination of Vim + tmux. I've seen this on different Linux flavours, i.e. on Ubuntu and Mint. I use the default terminal (Gnome Terminal 3.6.2) there.
So how can I prevent this?
EDIT: My tmux.conf
set-option -g prefix C-a
set-option -g mouse-utf8 off
set-option -g status-keys vi
set-window-option -g mode-keys vi
set-window-option -g mode-mouse on
set-option -g terminal-overrides 'xterm*:smcup#:rmcup#'
bind-key C-a last-window
bind-key C-h select-pane -L
bind-key C-l select-pane -R
# colors:
set-option -g status-bg black
set-option -g status-fg white
set-option -g status-left '#[fg=green]#H'
set-window-option -g window-status-current-bg red
EDIT 2: I've also tried without the above .tmux.conf, using tmux' default settings - no difference.
After more investigation I found the root of the problem. It's because tmux does not support the bce feature. From the xterm FAQ:
The term "bce" stands for "back color erase". Terminals such as modern xterm and rxvt implement back color erase, others such as dtterm do not. (Roughly half of the emulators that I know about implement bce). When an application clears the screen, a terminal that implements back color erase will retain the last-set background color. A terminal that does not implement back color erase will reset the background color to the default or initial colors. Applications that paint most of the screen in a single color are more efficient on terminals that support back color erase. Inevitably, there are tradeoffs and issues with standardization of the feature as noted in the ncurses FAQ. Unsurprisingly, ncurses supports xterm's behavior.
The original screen multiplexer had this feature. I've opened a feature request issue, but unfortunately they refused to implement it. So the hard truth is: There's no solution with tmux.
UPDATE: For those checking the feature request - Good luck! The author is very opinionated and reacts quite thin-skinned. He completely banned me from the repository, because I dared to counter one of his snotty comments. Take care.
Emm, I found a workaround, to change TERM to xterm from screen:
TERM=xterm vim
or use below in ~/.tmux.conf
set -g default-terminal "xterm"
Above I've tested in GNOME terminal's local shell and SecureCRT's remote shell.
If this still not works, maybe you can check you don't have "set t_ut=" in your ~/.vimrc or other global settings, because I find this break my workaround.
but in "man tmux", it says
"The TERM environment variable must be set to “screen” for all programs running inside tmux. New windows will automatically have “TERM=screen” added to their environment, but care must be taken not to reset this in shell start-up files."
and
"Set the default terminal for new windows created in this session - the default value of the TERM environment variable. For tmux to work correctly, this must be set to ‘screen’ or a derivative of it."
I don't know the side effect of this.
I'm currently using tmux with xterm-256color $TERM variable. When in bash under tmux, pressing home/end would insert tilde characters (~). Outside of tmux the home/end keys work fine.
Using cat and tput, I could see that there was a mismatch between the generated and expected sequences:
$ cat -v # pressing home, then end
^[[1~^[[4~
$ tput khome | cat -v; echo
^[OH
$ tput kend | cat -v; echo
^[OF
To fix this, I decided to add the following to my .bashrc:
if [[ -n "$TMUX" ]]; then
bind '"\e[1~":"\eOH"'
bind '"\e[4~":"\eOF"'
fi
That fixed the problem for bash, however in other readline programs, such as within a REPL such as ipython, it still inserts a tilde for home/end.
Why exactly is this a problem in the first place? Why is the generated sequence different when I'm inside tmux vs outside it? How can fix this so that it's not an issue in any programs?
It appears the main problem is with using xterm-256color for $TERM. I switched $TERM to screen-256color and the problem went away.
Add the following to your .tmux.conf:
bind-key -n Home send Escape "OH"
bind-key -n End send Escape "OF"
And you're done!
Explanation
After attempting each one of these, and several others I saw while perusing other answers and documentation, this finally worked for me in every scenario I threw at it. I can't promise the same for you, because everyone's scenarios are different, but this is what I ended up with.
This was discovered after introducing the same trial/error and logic from a somewhat relevant article that is no longer available. The key is where the translation is occurring; in my case, this happens within my .tmux.conf, rather than .bashrc or .zshrc (mainly because my home/end worked fine outside of tmux)
Debugging
You can debug this issue by using cat -v.
Run cat -v, then press the Home and End keys. Exit using Ctrl+C.
$ cat -v
Here's what my output looked like within tmux using zsh, zsh, and bash:
tmux
➜ ~ cat -v
^[[1~^[[4~^C
zsh
➜ ~ cat -v
^[[H^[[F
bash
bash-3.2$ cat -v
^[[H^[[F
Solutioning
Compare the above examples to what we're expecting to see, by pairing tput with cat -v:
$ tput khome | cat -v; echo
^[OH
$ tput kend | cat -v; echo
^[OF
Conclusion
Because this problem exists solely within tmux, and not within the shells themselves, I opted to make the bind changes within the tmux configuration instead. By using bind-key paired with send, we can use the Escape keyword paired with the sequence we want to achieve our translation. Thus:
bind-key -n NAME_OF_KEY send Escape SEQUENCE_GOES_HERE
This debugging and solutioning process can be applied to any other key translation issues. But, don't go too crazy. Some keys are mapped to certain escape sequences for a reason. Notice how bash and zsh received the ^[[H sequence for Home instead of ^[OH; it's probably not recommended we override this in our .zshrc unless we're having major issues with this in zsh.
In tmux 2.0, you can just add these 2 lines in your .tmux.conf:
bind -n End send-key C-e
bind -n Home send-key C-a
If you want to stay with xterm-256color in tmux for some reason - use arch solution with inputrc. I tested it in tmux with rxvt, ruby irb, python, lua and home/end keys are ok. Probably every readline app will be ok.
From the arch wiki:
First things first:
do not set $TERM manually - let the terminal do it.
Many command line applications use the Readline library to read input. So properly configuring Readline can fix Home and End in many cases.
the default /etc/inputrc file does not include a mapping for home/end keys.
To check what the emitted escape sequence for these keys is:
1. Ctrl + V
2. Home
3. Spacebar
4. Ctrl + V
5. End
this will probably print: $ ^[[1~ ^[[4~. So you have to add a mapping for these sequences to your inputrc (/etc/inputrc to be globally, or only for your user ~/.inputrc):
"\e[1~": beginning-of-line
"\e[4~": end-of-line
In my case it was a problem with zsh in tmux (bash in tmux was ok).
None of the other anwsers here worked for me.
But adding this to .zshrc fixed it:
bindkey "\E[1~" beginning-of-line
bindkey "\E[4~" end-of-line
Besides that I also have:
bindkey "\E[H" beginning-of-line
bindkey "\E[F" end-of-line
bindkey "\E[3~" delete-char
From 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", "tmux" or similar (such as
"tmux-256color"). Don't bother reporting problems where it isn't!
Outside, it should match your terminal: particularly, use "rxvt" for
rxvt and derivatives.
Add the following command to your ~/.tmux.conf:
set -g default-terminal tmux-256color
PS: any solution involving binding the keys explicitly is a hack, and as such bound to fail.
set-window-option -g xterm-keys on
This should work in tmux 2.6 and later. (tmux -V to check) If you are using an older version than that, you're probably running an older Ubuntu and you should definitely consider pointing at a ppa with backports.
This definitely doesn't work with kitty, and is effectively "hardcoding" the terminal in terms of input, but it is better than hardcoding specific keys.
So I don't have enough points to comment,so I'll say it here instead. I believe the preferred solution is using
set -g default-terminal "screen-256color" in your ~/.tmux.conf. I actually had this problem a while ago and decided to go with sumanta's solution :
bind -n End send-key C-e
bind -n Home send-key C-a
However I had forgotten I left this in here and ended up having a similar issue with vim (home and end were copy pasting from registers) instead of zsh. In short bind DOES affect vim.
I wasted a lot of time trying all off the above.
In the end I reverted to barbarism:
sudo apt purge tmux
sudo apt install tmux
fixed it for me.