I am attempting to use tmux from the web based terminal. I am running into the problem that my prefix key seems to be ignored (or, more probably, consumed by the browser or some such). If I ssh into the box, then controlling tmux works just fine. By default I have the prefix key mapped to 'C-\', but it doesn't actually matter. Even with the default 'C-b' keybinding things fail.
If there are collisions with browser shortcuts, have you tried editing your ~/.tmux.conf file?
https://wiki.archlinux.org/index.php/tmux#Configuration
I also remapped my caps lock key to control key as well which is much nicer IMO:
https://wiki.archlinux.org/index.php/tmux#Configuration
Related
I have a tmux session running in PuTTY, and I have tmux configured to use vim keybindings. I want to be able to use the visual highlight mode that vim keybindings provide (shift+V I believe), highlight some text, and then copy it to my Windows 10 clipboard. Is this possible?
I assume you are running tmux remotely.
If so, then for this to work you need a terminal that supports OSC 52. From a quick look at the putty code it doesn't appear to, so you will not be able to do this with putty.
However, you could try a different terminal that does support it, like mintty - it looks like you just need to turn its AllowSetSelection option on. IIRC mintty defaults to TERM=xterm, so if your tmux is new enough and you turn this option on, it should just work.
If it doesn't work, you need to check that Ms is set in the terminal-overrides option for the TERM you have outside tmux, and that the tmux set-clipboard option is set to on or external.
Until recently I have been using bash with tmux. Bash was behaving as I would expect it to behave, where the history is preserved in each separate pane, and is not shared between panes. However it looks like in zsh the default is for the history in the panes is to be shared. Is there a way to overwrite the default in zsh so that they are not shared when using in tmux?
Tmux should have nothing to do with this, really. So let's focus on your Zsh setup.
You’d have to jump through some hoops to get history to be real-time shared among running Zshs, so it’s surprising that you’re seeing this. What settings have you made to control your Zsh history? Run this to see your settings:
setopt |grep hist
For not saving history immediately, you’ll want:
setopt noincappendhistory
setopt nosharehistory
You can put that into your ~/.zshrc. You may want to log out of running shells to ensure your new settings take place.
For info on all the history-related Zsh options, see man 1 zshoptions and look for the “History” section a few pages in. Note that there are also some environment variables that impact history (SAVEHISTORY, HISTFILE, HISTFILEIGNORE, HISTSIE, HISTFILESIZE).
I am using the latest stable version of iTerm2 (2.0) with the latest Homebrew build of tmux (1.9a). Unfortunately, my keybindings as declared in .tmux.conf do not work with the iTerm2/tmux combo in "integrated mode" (i.e. when iTerm2 takes over the management of tmux windows and panes). I tried different prefixes (C-b, M-a) as well as different key mappings in iTerm, but to no avail.
Is this indeed an iTerm bug? Or is my expectation that the .tmux.conf keybindings would be carried over to iTerm a false one? Even my tmux command prefix (M-a) does not work!
You may view my tmux configuration file at https://gist.github.com/453ab63c42df976bc2be.
Someone reported a similar bug at iTerm2 Tmux Integration Default Keybindings not working in 2015. The response from the developer George Nachman suggests that keybindings are not supported:
One of the main goals of the tmux integration is that you use iTerm2's
keystrokes, not tmux's. If there's a specific workflow that you can't
accomplish natively, let me know--there is a lot of power in the
ability to remap keys in iTerm2.
As of this change in iTerm2, you can now set a Leader key / prefix in the iTerm2 config which will forward to tmux. You still can't bring up the tmux command prompt, but you can create new windows, panes, etc, and my custom keybinds appear to be in working order.
You can configure the shortcut in Prefs > Keys > Key Bindings > Leader... Once you define a leader, the tmux key combos will become available. I recommend cmd-B as the leader for muscle memory and because cmd-B isn't otherwise in use.
This is what it should look like, note my prefix is the ` key but you should set this to whatever your tmux prefix binding is.
As of this writing the feature is only in the nightly build of iTerm2, so you'll be running alpha code, but assuming nothing goes wrong it should be included in the next stable release (or 3.5beta6).
edit: Ben's answer that this is unsupported is correct. My advice does not apply to "integrated mode".
Make sure you don't have conflicting key mappings in iTerm, that your option key is set to Meta, and that you've tmux source ~/.tmux.conf after your changes (the config is only loaded by the server, so you have to restart all sessions or re-source). Also, if you're using Karabiner or another hotkey remapper, it could be interfering in some way.
You're starting with a rather extensive config - I'd start with a one line config for testing purposes.
Is this possible to do?
Conceptually, a solution should apply across a lot of possible configurations, ranging from two vim instances running in separate virtual terminals in panes in a tmux window, to being in separate terminals on separate machines in separate geographical regions, one or both connected over network (in other words, the vims are hosted by two separate shell processes, which they would already be under tmux anyhow).
The case that prompted me to ponder this:
I have two tmux panels both with vim open and I want to use the Vim yank/paste to copy across the files.
But it only works if I've got them both running in the same instance of Vim, so I am forced to either:
use tmux's copy/paste feature to get the content over (which is somewhat tedious and finicky), or
use the terminal (PuTTY, iTerm2)'s copy/paste feature to get the content over (which is similarly tedious but not subject to network latency, however this only works up to a certain size of text payload to copy at which point this method will not work at all due to the terminal not knowing the contents of the not-currently-visible parts of the file), or
lose Vim buffer history/context and possibly shell history/context in reopening the file manually in one of the Vim instances in either a split buffer or tab and then closing the other terminal context (much less tedious than 1 for large payloads but more so with small payloads).
This is a bit of a PITA and could all be avoided if I have the foresight of switching to an appropriate terminal already running vim to open my files but the destiny of workflow and habit rarely match up with that which would have been convenient.
So the question is, does there exist a command or the possibility of a straighforwardly-constructed (shell) script that allows me to join buffers across independently running vim instances? Am having a hard time getting Google to answer that adequately.
In the absence of an adequate answer (or if it is determined with reasonable certainty that Vim does not possess the features to accomplish the transfer of buffers across its instances), a good implementation (bindable to keys) for approach 3 above is acceptable.
Meanwhile I'll go back to customizing my vim config further and forcing myself to use as few instances of vim as possible.
No, Vim can't share a session between multiple instances. This is how it's designed and it doesn't provide any session-sharing facility. Registers, on-the-fly mappings/settings, command history, etc. are local to a Vim session and you can't realistically do anything about that.
But your title is a bit misleading: you wrote "buffer" but it looks like you are only after copying/pasting (which involves "register", not "buffers") from one Vim instance to another. Is that right? If so, why don't you simply get yourself a proper build with clipboard support?
Copying/yanking across instances is as easy as "+y in one and "+p in another.
Obviously, this won't work if your Vim instances are on different systems. In such a situation, "+y in the source Vim and system-provided paste in the destination Vim (possibly with :set paste) is the most common solution.
If you are on a Mac, install MacVim and move the accompanying mvim shell script somewhere in your path. You can use the MacVim executable in your terminal with mvim -v.
If you are on Linux, install the vim-gnome package from your package manager.
If you are on Windows, install the latest "Vim without Cream".
But the whole thing looks like an XY problem to me. Using Vim's built-in :e[dit] command efficiently is probably the best solution to what appears to be your underlying problem: editing many files from many different shells.
The default behavior for the [TAB] key in the shell is to automatically auto-complete or list the files in the current directory. How to override this behavior in the shell for some chosen applications?
Edit: This is not related to the application that is being used, rather, it's the shell environment that needs to be customized! (Thanks to Anders Abel for clearing this point)
If you want to change the behaviour when creating the command line for starting the program, that's impossible from within the program. At that point your program is not yet started, so it's entirely up to the shell how to interpret [TAB] at that point.
Once your program is running you can of course handle [TAB] in whatever way you want, by using an appropriate API call.