On macOS, if use bash or zsh shell, use Ctrl+C can copy string to clipboard immediately. But at Tmux model, it can’t. Should press option key, then use mouse select string, press Ctrl+C. It’s a little complex. Is there a short way to do if set any option in Tmux config?
I think tmux = terminal multiplexor: some terminals inside another terminal. If Ctrl+C works when zsh is inside a native terminal (iTerm or xterm), but Ctrl+C doesn't work when zsh is inside tmux; then, that Ctrl+C is the feature of that native terminal (iTerm or xterm) not a feature of zsh or bash.
It is impossible to assign a same key shortcut for BOTH native terminal (iTerm or xterm) AND tmux (which runs inside THAT iterm or xterm).
If you prefer to use tmux (nearly) all the time, then you have to disable Ctrl+C key shortcut in the native terminal (iTerm or xterm), then set it in tmux. But I think most of users wont do that. They have to select a different set of key shortcuts for tmux without changing the native terminal settings, which they already get used to for long time.
Related
I am trying to get tmux to use screen-256color instead of xterm-256color, as it is not recommended. But when I am not using tmux, I would like to keep it as xterm-256color
A little bit of my setup, I am currently using iTerm2 and ssh to my development linux box, which is using zsh.
In my ~/.zshrc, I have:
export TERM="xterm-256color"
In my ~/.tmux.conf, I have:
set -g default-terminal "screen-256color"
With this configuraiton, without tmux, echo $TERM returns xterm-256color (which is right) and with tmux, echo $TERM is still returning xterm-256color instead of screen-256color.
Is there anything else I need to set in order for this to work?
Thanks!
The reason this does not work as expected is, that the zsh session that is started inside tmux overwrites TERM.
You should not set TERM from within in your shell. TERM is the way the terminal informs the shell and other applications about its capabilities (number of colors, key sequences for special keys, etc.). If you change TERM inside the shell, you change the what features the shell and applications expect from the terminal without the terminal itself knowing about it. Oftentimes this may not be an actual issue, but it is better to change the terminal configuration and set the desired value there.
You already did so when setting screen-256color in the configuration of tmux, which is essentially a terminal emulator, too. To do it for iTerm2 (tested with version 3.0.10):
Open the Preferences dialog (in the Menu: iTerm2 → Preferences, or press ⌘+,).
In the dialog go to Profiles → Terminal.
There you can choose the desired value for TERM under Report Terminal Type.
You could modify your .zshrc file to check if you are running in tmux:
[ -z "$TMUX" ] && export TERM=xterm-256color
Is it possible to reuse backgrounded emacsclient windows, when invoking emacsclient?
Here's some background information (I mainly use emacs in terminal mode, not gui frames)
When the computer boots, an emacs daemon is started.
In the OS X terminal when I want to open a file, I do emacsclient /filename -nw
Now when I want to do bash stuff I press C-z to background emacs.
Now emacs appears in the jobs command. The fg command would also
make it re-appear.
But while I'm browsing around in bash, I see another file I want to open.
Now, how can I reuse that minimized emacsclient session with a single command?
Yes, put this in your .bashrc:
ec() {
kill %emacsclient 2> /dev/null
emacsclient -nw --eval '(find-file "'"$PWD/$1"'")'
}
Open files with ec file.txt. It's a bit hacky, but I think it will do what you want it to.
I open the file find-file so it'll stay open after you close the Emacs window (C-x C-c). Then when you open a new file, I kill the old Emacs window and open a new one. The effect is that the old file stays open forever, so it seems like you reused the Emacs window.
I copy text from outside of Vim. ⌘V in other apps pastes text without problem. In MacVim, it doesn't work.
In Insert Mode, nothing appears. In Normal Mode, I get E353: Nothing in register +. This happens when set clipboard=unnamed is on or off.
Oddly enough, this was working before. What's wrong?
If you are using tmux and sometimes you initially launch MacVim via the mvim command-line program, then you might be encountering the problem that prompted me to write the reattach-to-user-namespace command.
My guess is that clipboard access worked on prior occasions because you happened to have launched MacVim via a “normal” GUI method (e.g. the dock, Finder, Spotlight, etc.). The clipboard later became inaccessible after you had quit the prior instance of MacVim and relaunched it through (e.g.) mvim from inside a tmux session.
The core problem is that programs launched in certain contexts (i.e. inside a tmux session) end up with an environment that denies them access to certain services (e.g. the OS X pasteboard).
The initial launch is the important one here. New windows started by mvim-in-tmux (even without the above-linked wrapper program) should have access to the clipboard as long as MacVim was previously started “via the GUI” (maybe there are still some MacVim windows open, or maybe you have MacVim configured to keep running even when there are no windows open). Correspondingly, to regain access to the clipboard you will need to close all your existing MacVim windows, quit the application, then restart it in a way that has access to the clipboard (e.g. via the GUI, or “inside” the wrapper).
Once you have the above-linked wrapper program installed (it is also available through MacPorts and Homebrew), you can use a command like reattach-to-user-namespace mvim to ensure that if it ends up starting a new MacVim instance, then that new instance will have access to the clipboard. You might use an alias, shell function, or a script to make sure you always “wrap” mvim.
Several other commands also benefit from “wrapping” (pbpaste, pbcopy, nohup, launchctl (depending on which subcommand you are using)), so you may want to “wrap” your whole shell instead of the individual commands. The bit of the process environment that the “wrapper” modifies is inherited by child processes, so “wrapping” your shell will affect most commands you run from it. If you are using tmux, you could configure your default-command to automatically “wrap” your default tmux shells:
set-option -g default-command "reattach-to-user-namespace -l zsh"
I feel sure this will end up as a duplicate, but I don't know how to word it so that I can search for it...
I like to do my programming in emacs, which I launch from the terminal. When I use my mac I use aquamacs and the command
aquamacs Program.py
will launch aquamacs in a separate window ready to edit Program.py. When I work on my linux machine however to get the same result I must type
emacs Program.py &
And I'm always forgetting the "&". So 70% of the time I end up closing the emacs window, and relaunching again with the "&". Now I understand why that "&" is there, but is there a way to set up my system so that the command
emacs Program.py
always launches as a detached process? The only time I might not want that behavior is if I was SSHing in over a slow connection, in which case I usually use "-nw" anyway.
You can click on the terminal and press Ctrl-Z to move an already running foreground process to the background.
Alternatively you could add this function to your ~/.bashrc:
emacs() {
command emacs "$#" &
}
For the specific case of emacs, I use a shell script, which is more complicated than this but for your purposes boils down to
#!/bin/csh -f
/bin/emacs $*:q &
Put it in a directory which is earlier in your $path than where the "real" emacs is, and replace /bin/emacs with the real path to emacs on your system.
I'm using tmux on a macOsX moutain lion (10.8)
Whenever i'm in a terminal, pressing the Escape button results in the connection to the server being lost and tmux actually exiting. I experience the same behavior regardless in iterm2, terminal and while using any of zsh, bash or a normal login shell.
That's how it looks like:
Any hints? :)
I finally figured out that it was related to iterm2-tmux integration.
As you can read here in the Usage section just below the code box, the tmux-iterm2 integration makes the ESC key actually kill tmux, unless you actually use tmux -C.
This effect was actually undersirable for me since I was not using tmux -C and the ESC key is extremely important in programs like vim or mc.