I'd add <prefix> w to that list, which shows an interactive list of opened windows which is very friendly to newcomers, does away with the base-index setting that's needed to fix cognitive dissonance of tab order vs key order, and circumvents the inconvenience of having to use shift to reach for numbers on non-US layouts.
> Ctrl a (a little faster to type, doesn’t conflict with vim
... but conflicts with beginning-of-line emacs-style bindings, widely in use in readline/libedit/zsh.
I think I could live w having to “quote” ^Z to suspend a job, but worry I’m going to have ^Z baked-into my muscle memory and end up accidentally suspending jobs on non-tmux sessions.
I'd add stuff too, but I think we need to resist the temptation. The article succeeds in presenting the absolute bare minimum you need to get started. In fact, I think the author chose his features well but used too many words to present them.
C-a seems to be quite a common prefix, but as you said, it conflicts with the beginning-of-line command. I’ve been quite happy with C-s so far; if it conflicts with something, I have no idea.
C-s searches forward where C-r searches backwards, if you're used to using C-r to retrieve an earlier command via incremental search.
If not otherwise configured with stty, it's frequently set up for control flow along with C-q. If you find your terminal freezes after typing C-s, C-q will unfreeze it.
Ctrl-j is excellent for me as a vim user. It's default behavior is to just move the cursor one line down which you can already do by pressing... j (although Ctrl-j can be used in insert mode if I recall correctly).
As a long-time ‘screen’ user, the Ctrl-A issue is almost completely a non-issue. One can easily send a Ctrl-A to the underlying shell using Ctrl-A A. I assume ‘tmux’ has something similar. It’s also pretty rare to need the “beginning of the line” movement in a shell, when compared to the number of times one needs to control the multiplexor. Ctrl-A is also very close at hand, and the vast majority of people are using PC keyboards which also have a Home key that work just as well for movement.
C-b is pretty bad for the same reason for users like me with with well-worn emacs key memory. I end up using the backtick, but it does make sharing a session that little bit more difficult.
Nevertheless, I think they should have changed that in the release version and configure their dev environment. After all, it is pretty uncommon to run tmux inside screen for most use-cases.
Tmux is awesome. Although I never understood why they used ctrl-b instead of ctrl-a as the default though - incompatible with screen and hard to reach with one hand.
The home key is in a terrible, terrible place on the keyboard and missing in many laptop keyboards. Ctrl-A is much easier to reach while touch typing, especially after remapping Caps Lock to Ctrl.
And my own personal muscle memory prefers a different setup, so that's why these things should be configurable, but the defaults should probably match common conventions don't you think?
I disliked ctrl-a and ctrl-b as prefixes because both conflict with using emacs keybindings. However, it was convenient that, by default, they were different. When I first used tmux I was still using screen on some servers (that I didn't fully control). Being able to use screen on the server through my tmux session without having to double type the prefix was useful.
CTRL-A is the default for GNU Screen, and when you're developing a terminal multiplexor, you sometimes want to work on it inside the terminal multiplexor you're hoping to improve upon. :)
Thanks for sharing this! Vim is the kind of tool I use all the time, but never check for new features. Will definitely use :terminal all the time now :).
(For anyone interested, it looks like only more recent releases of vim 8 have :terminal.)
Yes, it was added only recently after Neovim showed the idea of terminal buffers to be feasible.
So it may not be available on $random_rhel6_server, but since the article described the scenario of a development server, I figured that package versions on there should be fairly recent.
nvi (default vi on (I believe) Net (and therefore Minix), Free, and OpenBSD) supports what sounds similar via “:script”. You have to split your window (or fg/bg the buffer) manually, though.
When working remote from a DSL line with random disconnects or stupid 24 reconnects / ip address changes, or via unreliable mobile tethering, a screen/tmux session saves you from accidentally killing important, long running jobs or missing important outputs, among other things.
A while ago I saw comments here about tmuxinator. Which was a fantastic improvement to my tmux use. Create a layout manually, get the layout from tmux and then set it up to launch a custom set of windows, panes, and programs based on my project needs. Doing this easily and repeatedly makes it trivial for me to set aside a task and come back to it later and be confident I will have everything in view that I need.
I could never get into tmux since it doesn't play nicely with iTerm2 and the mouse. With iTerm2 panes, you can select/copy/paste text within the pane even if it's over multiple lines. In a tmux session, you select all text across all panes.
Ditto goes for scrolling: Native windows scroll more naturally than tmux with mouse support.
70 comments
[ 3.0 ms ] story [ 191 ms ] thread> Ctrl a (a little faster to type, doesn’t conflict with vim
... but conflicts with beginning-of-line emacs-style bindings, widely in use in readline/libedit/zsh.
I'd add stuff too, but I think we need to resist the temptation. The article succeeds in presenting the absolute bare minimum you need to get started. In fact, I think the author chose his features well but used too many words to present them.
If not otherwise configured with stty, it's frequently set up for control flow along with C-q. If you find your terminal freezes after typing C-s, C-q will unfreeze it.
Disable with:
so much quinning
https://github.com/tmux/tmux/wiki/FAQ#why-is-c-b-the-prefix-...
Nevertheless, I think they should have changed that in the release version and configure their dev environment. After all, it is pretty uncommon to run tmux inside screen for most use-cases.
[dupe] https://news.ycombinator.com/item?id=15776995 (267 points, 96 comments)
Surprised to see it again so soon -- darn you Medium flexible URLs!
PS. Anyone willing to earn $400 implementing mosh ssh port forwarding https://www.bountysource.com/issues/4471419-ssh-port-forward..., or should I move on to the mentioned alternative https://mistertea.github.io/EternalTCP?
PPS. Bountysource feels sketch: https://hn.algolia.com/?query=bountysource
https://github.com/MisterTea/EternalTCP/issues/79
:D
Nowadays I use C-z: easy to hit with one hand, and easy enough to do C-z C-z if I actually want to suspend something.
See the tmux FAQ: https://github.com/tmux/tmux/wiki/FAQ
vim 8 has a built-in terminal.
will open a new buffer in a split window that executes the given command line. And it even supports all the regular vim keybindings. for details.(For anyone interested, it looks like only more recent releases of vim 8 have :terminal.)
So it may not be available on $random_rhel6_server, but since the article described the scenario of a development server, I figured that package versions on there should be fairly recent.
https://github.com/tmuxinator/tmuxinator
Ditto goes for scrolling: Native windows scroll more naturally than tmux with mouse support.
1. iTerm2 has tmux integration, a new panel in tmux automatically maps to a new tab in iTerm2 2. You can enter copy/paste mode in tmux.