Scenario: I open a new tmux session, and run emacs .tmux.conf.
The second line of .tmux.conf reads: set-option -g prefix C-a. I type 'asd', and the second line now reads: asdset-option -g prefix C-a. All good.
I ssh to another server, do some stuff, and then close the connection. I now re-run emacs .tmux.conf, and type 'asd'. The second line now reads asd-option -g prefix C-a, but if I save and run emacs .tmux.conf again, I'll see asdset-option -g prefix C-a.
This issue affects all lines except the first, even when I'm typing commands in the prompt.
Sourcing .bashrc, resetting the pane with respawn-pane, does not fix this. If I create a new pane or window, the issue is fixed in the new pane or window until I run ssh again.
What's happening? It's clearly a display issue, since inspection of the actual file reveals that i'm not actually overwriting.
To fix the problems of this kind, type in your shell:
$ stty sane
This is generally an universal one-time fix for terminal left off in a weird state.
To get rid of the problem completely, check your $TERM environment variable.
Inside tmux it should be TERM=screen (some suffix may present).
tmux does this automatically but your TERM environment variable can be altered by shell startup/login scripts.
So, in your tmux window type:
$ export TERM=screen
$ emacs <...>
If it helps, revise your shell rc files.
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
Does tmux support saving to a file the commands typed in "C-b :" mode ? I'd rather look through the ones I already typed than have to look each command up in the man page.
There is history-file option which does what you are looking for.
history-file path
If not empty, a file to which tmux will write command prompt history on exit and load it from on start.
Add this to your .tmux.conf
set -g history-file ~/.tmux_history
Note it was added in 2.1 version. if you have older version of tmux read
https://unix.stackexchange.com/questions/26548/write-all-tmux-scrollback-to-a-file
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 using CentOS 6. Since the CentOS repos have an older version of vim (7.2), I have compiled my own. However, I am having a weird issue. After running and exiting vim, I've found that my shell prompt has disappeared. Also, when I type, it does not appear in the terminal, nor does any output. What's weird is that it looks as though something is being outputted, since the cursor will move down the screen, but I can't see anything.
It must have something to do with compiling an X version, because it does not happen when I compile vim without X windows support (but I would like to have gvim, too). Here are the configuration options I supplied when compiling:
./configure --prefix=$OPT/Cellar/vim/7.4 --with-features=huge --enable-gui=auto --with-x --enable-xim
I also tried compiling without Xim. I've also tried explicitly setting --enable-gui=gtk2 (which is what gvim 7.2 from the CentOS repos uses).
I am using KDE4. The problem occurs both when running tcsh and bash. I have tried with $TERM set to both xterm and xterm-256color as well.
Additionally, running neither reset nor stty sane restores the shell to its proper behavior.
Any idea why my prompt disappears when running vim? As I missing a config flag or some other compilation issue?
I ultimately traced this down to an error in my ~/.vimrc file. I had some lines like this:
if has('gui_running')
# Gvim customization
endif
if has('gui_gtk2')
# GTK2-specific Gvim customization
endif
The second block was running every time vim loaded. Because it changed some window geometry, it ended up messing up bash; when I dropped back to bash, bash thought it only had ~53 columns to work with (and possibly some other things were messed up).
Solution: The second if block should be inside the first.
SOLVED: the problem was this line in my .vimrc:
set shell=/bin/bash\ -li
UPDATE: it appears the problem is due to my .vimrc (renaming the .vimrc to 'hide' it fixed the problem), so it probably has nothing to do with Mint.
I'm running Linux Mint 17 Cinnamon. When I run vim -d file otherversion in the terminal, I get a blank screen with
"otherversion" 18L, 218C
[1]+ Stopped vim -d file otherversion
user#machine:~/path/to/directory$ ;2R
If I do fg 1 that terminal window just closes. Also, there's no blinking cursor, though I am able to type. Same with vimdiff instead of vim -d. I've tried multiple distributions of vim, some that include the GUI, some that don't.
However, with versions that do include the GUI, if I run vim -d -g file otherversion, it works as expected.
I'd rather not depend on gvim to use vimdiff.
Any advice?
Thanks
If you need an interactive bash shell (to get your bash aliases for instance), use this code in your .vimrc instead of removing the option:
if &diff == 'nodiff'
set shellcmdflag=-ic
endif
This will only enable the interactive bash shell when not running vimdiff, so that you will have you bash aliases when running vim.
After removing the following line from my .vimrc, the problem went away:
set shell=/bin/bash\ -li
Thanks to comment from #FDinoff, the same problem at my end got solved.
The problem was "bash" command in my ~/.cshrc.
I had put that to avoid entering into bash every time after login. It was working fine until this issue started coming whenever I used to open vimdiff.
Removing ~/.vimrc didn't help me either. Then I read comment from FDinoff. There, he suggested that it could be related to shell, if "less" and "man" have also stopped working. I observed the same issue in my case, that helped me rule out the corruption in .vimrc.
After removing "bash" from my ~/.cshrc, the problem went away completely.