I have recently started trying out the tool tmuxomatic and observed the following behavior which I find undesirable.
In my .tmux.conf, I have the following keybinding.
bind u set synchronize-panes
When I launch tmux normally, if I use the u command, it will synchronize panes and also briefly flash a message in the status bar to let me know that my command went through.
However, when I launch tmux using tmuxomatic, the u binding still works, but there's no flash at the bottom.
I skimmed the source code for tmuxomatic but did not see anything obvious that would cause the suppress the flashing behavior.
Does anyone know which tmux option would cause the status bar to no longer flash on a command, or possibly flash so quickly I cannot see it?
I also tried the command :set synchronize-panes directly and reproduced the same problem, so it is independent of the keybinding.
The output of version commands.
tmux -V
tmux 1.8
tmuxomatic -V
tmuxomatic 2.18
After searching for a while in all the wrong places (tmux source code), I returned to the tmuxomatic source code, and noticed that it had a command line option -p which printed out the tmux commands it executed.
Among the commands printed, I saw the following command, which looked promising.
/usr/bin/tmux set-option -t tmuxomatic_Test.mux quiet on
I ran all the commands manually while excluding this command, and observed that the hiding of status messages no longer occurred, indicating that this was indeed the culprit.
Related
Whenever I enter a terminal command in vim (e.g., !echo hello), I am momentarily kicked out to view the result of that terminal command and then prompted with Press ENTER or type command to continue. This is a bit jarring. I would like to stay within vim and with the command output printed out at the bottom.
I know vim :read will take the terminal output and actually put it into my buffer, but that is not what I am looking to do. Here is some reading if you are interested in a tangent.
It looks like when I run vim in Screen I get what I am looking for, but I am trying to get this to work with tmux and the stock Mac terminal.
After a ton of research, probably too much, I got it! It looks like vim will send commands to the terminal, which in turn defines the behavior of how the terminal commands are processed from vim. Put this into your .vimrc file:
set t_ti= t_te= " show results from terminal commands within vim!
From what I understand, this just makes sure to send nothing to the terminal, which yields my desired results!
Side note: the above addition to your .vimrc file will also prevent the vim buffer from clearing when exiting vim (e.g., :wq). I am okay with this! It is kind of nice sometimes to see what you were just working on :).
First off:
I'm using tmux 2.5 installed via homebrew on OS X 10.12, in iTerm 2 (though the problem appears in Terminal.app as well). My tmux.conf is on Github, along with my zshrc.
The problem: Seemingly out of nowhere, I started seeing an issue with typing in the prompt. Typing keys once will display them twice, and backspacing will move the cursor forward and redraw characters already present on the line. This only happens inside of a tmux session, and not inside my "regular" terminal.
Here's a gif of the issue. In this gif, I type 1234567890, then hit backspace 9 times, and type ls. Note that 0 only shows up once, and lls with a duplicated l runs the ls command as expected.
Hopefully I just hit a weird key combo on accident, but I've been stuck on this for a while.
Thanks for any help!
Installing tmux-256color for macOS as in this guide solves the problem.
Running the following as mentioned in a github issue solved the problem for me:
brew install ncurses
$(brew --prefix)/opt/ncurses/bin/infocmp tmux-256color > ~/tmux-256color.info
tic -xe tmux-256color tmux-256color.info
infocmp tmux-256color | head
I'm also running into this issue as well. I encountered the problem similar to #artemave, by trying to change the set -g default-terminal "screen-256color" to set -g default-terminal "tmux-256color". The goal of doing this was to gain italics, per the tmux FAQ.
#taylor's answer didn't work for me, as I didn't have that command.
I managed to determine that:
The issue doesn't occur with bash
When running a blank .zshrc, backspacing creates new blank lines, but I'm not seeing the character duplication
Using tmux-256color will successfully give italic fonts
Using TERM=xterm-256color and TERM=konsole-256color does not change the above effects
Using xfce4terminal (0.8.9.1), Konsole (19.12.3), or URXVT (9.22) doesn't change the above behavior
I wasn't able to really "fix" the issue, as the even going down to a blank .tmux.conf wasn't able to change anything. Instead, I just needed to change it to anything else. xterm-256color was suggested in this issue, but I found nearly anything else would work fine.
I'll keep working on it and update this answer if I find anything else.
Edit: This tmux issue is the exact issue we're running into. I'll see if the solutions there work
https://github.com/tmux/tmux/issues/597
Edit 2: I've submitted a GitHub issue with tmux. No real results yet, but it does offer some guidance on things to check on.
The problem seems to be fixed after commenting out this line from my tmux.conf:
set -g default-command "reattach-to-user-namespace -l zsh"
I also had to manually run tmux kill-server instead of relying on just re-sourcing my conf file.
When I find some time, I'll look more into what went wrong here...
I have Vim on Windows server 2012, and when I start it from the start menu everything works fine. However, when I start it from the command line it take 5 seconds and uses 700MB memory. Even when its not opening a file. There is something weird going on, and I was wondering if there are any ways to debug it/figure out what is causing this? Thanks, Eric.
EDIT:
Here is the result of vim --startuptime outputfile (abbreviated):
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.000 000.000: --- VIM STARTING ---
...
016.000 016.000: parsing arguments
016.000 000.000: expanding arguments
4794.000 4778.000: shell init
4794.000 000.000: Termcap init
...
4825.000 000.000: setting raw mode
8768.000 3943.000: start termcap
8768.000 000.000: clearing screen
8783.000 000.000: --- VIM STARTED ---
You could use Sysinternals' Process Explorer to check if any of the processes are starting child processes or if there is any difference in the environmental variables.
Also, Sysinternals' Procmon would allow you to check what registry entries, files, etc does any application use (filter by command name includes vim), but probably you will find the differences just with Process Explorer.
Sysinternals was a company that created some nice apps for Windows and Microsoft bought it some years ago. You can access the last version of any of their apps on http://live.sysinternals.com
Excerpt from Vim FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual runtime
files or any plugin that is distributed with Vim or whether it is a
simple side effect of any configuration option from your .vimrc or
.gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your viminfo
file (-i NONE), without reading any configuration file (-u NONE for not
reading .vimrc file and -U NONE for not reading a .gvimrc file) or even
plugin.
In this invocation, try to reproduce your problem. If the error
persists, the chance is good you've found a bug in Vim (see also
Question 2.6. faq-2.6)
If the error does not occur when starting Vim this way, then the problem
is either related to some plugin of yours or some setting in one of your
local setup files. You need to find out, what triggers the error, you
try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load any
plugins. If the error occurs this time, the error is possibly caused by
some configuration option inside your .vimrc file. Depending on the
length of your vimrc file, it can be quite hard to trace the origin
within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half of
your .vimrc. If it doesn't happen, the problematic setting must be in
the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and move
your way along, until you find the problematic option.
It also mentions how to create a log file:
You can also use the -V command line argument to get more debug
information to analyze the problem:
$ vim -V2logfile
You can increase the value passed to the -V argument to get more debug
information. By also specifying a logfile name, this makes sure, the
debug messages don't appear on the screen and won't disturb you when
trying to reproduce the problem.
I am on OSX Mountain Lion. I've configured tmux.conf to lock the screen, but the screen only flashes, no locking takes place. (fyi, when i used GNU-screen, the screen did lock).
My system does not have a lock/slock or vlock, nor could i find these on homebrew or macports. I understand that Screen uses its own internal locking whereas tmux uses external locking. I do not care whether I am asked to enter a new passkey or the system password is used. So how to get tmux to lock the session/terminal ?
# Screen lock
bind-key C-x lock-server
bind-key x lock-server
bind-key -n M-x lock-server
set-option -g lock-after-time 0
set-option -g lock-server on
# set-option -g lock-command "vlock"
p.s. I am aware of other alternatives, but these typically require a mouse (hot corners) or a Mac keyboard (eject key).
As far as I know, OS X does not supply any variation of the tty-locking program that tmux requires.
You will probably need to find a third-party tty-locking program, try to port one from a related OS, or write your own.
This isn't an exact answer as you expected. #chris-johnsen gave the best answer about locking on OSX. I did however find two screen savers for the terminal. It doesn't lock the terminal but it does blank out the screen.
tmux has a built in time function that will blank the screen and display a clock. It is local to the window.
cmatrix is a terminal program that displays the matrix screen like in the movie. The con is that it doesn't lock and it eats up some CPU. But it is fun. It can be installed via homebrew
Here is how to get it working:
brew install cmatrix
Then add this to your ~/.tmux.conf:
set -g lock-command "cmatrix -s -b"
set -g lock-after-time 90
set -g lock-server on
In 90 seconds of inactivity it will display. Use the command tmux lock-server to test it.
I was disappointed to not see any valid responses for actually locking the screen. I'll continue looking for a way to properly lock the terminal session itself, but in the meantime I do have a functional alternative.
By running a command on the command line, you can lock your entire mac. The following command will make it happen:
/System/Library/CoreServices/Menu\ Extras/User.menu/Contents/Resources/CGSession -suspend
You can find a lot more about what's happening exactly at this page.
Tie that command into:
set-option -g lock-command
And you should have a way to functionally lock up your session. I know locking the entire machine is not the most desirable outcome, but this is at least a working alternative for now.
I have just installed darcs 2.1.2.2. When I type darcs help, sth less-like shows up. When I dismiss it with q it goes away but I don't get prompt and can't execute any commands. C-c doesn't work either. I am using bash on gentoo.
I have no idea what darcs is, but when bash fails to return to the prompt that some command as part of a pipeline is still running. For instance if you ran:
cmd | less
And exited less, but cmd did not die from a broken pipe, then cmd would continue to run and bash would continue to wait until it exited. It also might not respond to signals and keypresses if it didn't have access to the tty.
You will need a second terminal to check and see if any processes are hanging around after trying to dismiss darcs. Sometimes Ctrl-Z or Ctrl-\ will work where Ctrl-C doesn't. There is probably no fix other than to look at darcs and figure out why it is not dimissing like it should. If it is really launching less, then maybe typing ">" before "q" will make it exit properly.
In this situation (terminal messed up, can't see what you're typing) the "reset" command will often fix things.
I would try again with a newer darcs, eg version 2.3 released today. If the problem still happens, you can probably change this behaviour - see the darcs manual. Otherwise, folks on the #darcs irc channel will be able to help.