I discovered i3 and the concept of tiling window managers a few years ago and have never looked back. A new terminal or browser window is always a keystroke away, as is swapping between "pages" of windows. It's all navigable completely by keyboard, so my vim/i3/dmenu editing environment has me very rarely touching the mouse. As an added bonus I get to use every part of the screen by default. No wasted space.
It's also pretty trivial to get some nice window arrangements so that I can quickly move to relevant parts of the code for whatever I'm working on.
I guess the major trade-off is that there aren't any menus for accessing functionality, but I personally consider that a win because I end up being forced to learn how to manage everything at the lowest config level, usually editing text files. This makes it vastly easier to script things when I realize I've been making the same changes over and over.
So if you like tmux and you're on Linux, I'd strongly recommend giving i3, awesome, or some other TWM a try.
I think you might be missing half of what tmux does. The tiling/multiplexing part is one half. The other half is the fact that it spawns a session that can run persistently in the background and which you can connect to from anywhere. You can also disconnect, let it sit there for a week, come back and it'll still be there exactly as you left it.
I use tmux as my primary "IDE", and it's absolutely indispensable being able to connect to my tmux session from any computer anywhere. I actually run tmux on one remote machine, and from my tmux session I ssh to 15+ other machines. I also use it as a tiling window manager, and I make full use of that aspect of it by generally maximizing my terminal so that it fills up a standard 27" 1440p monitor. If I'm working from a small laptop, it's a little less ideal, but all I have to do is select the right window and then use tmux's built-in zoom feature to maximize that one window. It works beautifully overall.
i3 is fantastic, but it can't replace tmux if tmux is being used to the full extent of its capabilities.
Yeah, tmux has two functions, and that's my (and others') problem with it. Instead of doing one thing well, it does two things poorly. It's not a very good window manager; when you use tmux you can't easily put a graphical window between two terminal screens. Even as a text-mode-only window manager it's lacking. It has poor mouse support, and every command you send to it has to first be announced with a prefix keystroke.
It's also not very good at keeping programs running. It can't survive a reboot, for example. It's possible to do that, and there's stable software that does it. Generally any program that can handle a suspend and resume can handle being persisted across reboots.
Not that I have a great suggestion for alternatives — I'm not really in the market right now. I use i3 for window management (not 100% satisfied, but it's definitely high quality software). I don't often run long-lived processes in ssh sessions these days. When I do, I use tmux, which is fine, I guess, if I don't have to do it often.
> Instead of doing one thing well, it does two things poorly.
It really doesn't. I think you just wanted something to say.
> It's not a very good window manager; when you use tmux you can't easily put a graphical window between two terminal screens
I think wanting to do that is your problem. I appreciate you may have your own insane use case, but mixing x/ptty makes no sense. Try just using your WM to switch to it.
> It's also not very good at keeping programs running. It can't survive a reboot, for example. It's possible to do that, and there's stable software that does it.
What are you even talking about? How is it supposed to know what your running and why you want to keep it running? Do you want your operating system suspend? Do you want to use docker pause/unpause? Then do. You can even script this stuff, which a number have done.
If your workflow unique to you then don't blame a tool designed for a different workflow
> > Instead of doing one thing well, it does two things poorly.
> It really doesn't. I think you just wanted something to say.
I'd say it does at least three things: terminal multiplexing, session management and copy/paste.
I switched away from tmux a while ago and now use DVTM for multiplexing and dtach for session management. DVTM delegates copy/paste to an external editor, but I've not used that functionality.
> every command you send to it has to first be announced with a prefix keystroke.
That's not a bug - that's exactly how every container-style program should work. That way, whatever is running inside the container, talking to the container can never get in the way. It's probably the most frustrating thing about web browsers and most window managers.
I went to effort to make my current window manager work that way (after getting used to it in ratpoison and, of course, screen/tmux).
Well I can appreciate the idea, and there's no other solution that can handle all cases of multiple levels of nested applications that all have their own keybindings (like a web app inside of a web browser inside of a window manager). But in practice I find it to be a horrible experience to use. I used a typical hipster OS X + tmux + vim setup for over a year a while back, so I speak from experience.
Graphic software vendors have essentially all agreed to never use the super key (aka windows key aka command) in their default configuration, an artifact of the time when you couldn't rely on computers having a super key, and of Windows reserving the super key for itself. Most modern window managers only use keybindings that involve the super key. Or at least Gnome 3 does, kinda, except for alt-tab and a few other bindings. Anyway, my window manager config only uses keybindings involving the super key.
It's a much more pleasant window management experience.
But yeah, I don't think there's an alternative that tmux could have used (though mouse integration could alieviate a lot of pain). But that's in itself an argument in favor of not using tmux to manage windows.
You can configure prefix-less keybindings for tmux. It might not be a good idea to do globally unless you know that none of your terminal apps will depend on the same key, but having that in per-project (or per-language) configs might be ok.
I find mouse and clipboard support a bit annoying but there's been changes to that in recent versions of tmux and I haven't reviewed what they do yet.
I haven't got to that part quite yet, but I've been considering adding a few global key shortcuts that would route e.g. run/continue/next/step to my debugger window, regardless of which tmux window is active.
> Generally any program that can handle a suspend and resume can handle being persisted across reboots.
This is not the case for very many of my processes. Are you suggesting DMTCP or something? That won't work with most of the stuff I'm running in terminals.
Other people thought that way I believe, hence the existence of dtach and dvtm. The nice argument is that by decoupling the two functionalities, you get two very tiny binaries instead of one quite ~larger tmux.
Well, not to be too snarky but you _are_ running screen/tmux in a terminal window.
And I hope I'm not the only person who considers having to move my hand off the keyboard and onto the mouse a UX bug.
every command you send to it has to first be announced
with a prefix keystroke
A friend of mine revolutionized my life when he showed me how he'd remapped GNU screen's command key from Control-A to backquote (`). Using screen went from being moderately annoying---especially to a die-hard Emacs user like myself---to being an essential part of every Unix/Linux server install I have done since. To be honest I don't understand why screen and tmux don't default to backquote instead of Control-A/Control-B, but maybe that's just the twenty-plus years of Unix-induced brain damage talking. :)
Probably because backquote is very often used by many people. In particular, people like myself who do a lot of Lisp programming. Outside Lisp, backquote is also used in sh (unless you want to give yourself RSI by using $(...)).
And this is the problem in a nutshell, there really is no single keystroke that everybody can agree is the perfect one to use. You obviously don't use backquote much, so for you, thats the perfect one. For me, Control-W is pretty good, unless of course I have to run Emacs at which time it becomes a terrible choice.
I use backquote pretty heavily, but I find typing "``" to get a literal backquote in the terminal to be much easier (and less stressful on my hands on modern PC keyboards) than "C-a a" to get a literal Control-A. YMMV.
Yes, I noticed. I also noticed that it doesn't justify that assessment by anything more than referring to ` as "legacy".
I'm not sure how much trust I would put into shellcheck. Especially since it doesn't flag the common error of "export FOO=bar" (instead of "FOO=bar ; export FOO").
Agree 100%. And I wrote a book on tmux. I would love something like i3 on my Mac. I can't give up OSX because I need its accessibility features because I'm low vision.
But if you're on Linux and you're not using i3, gosh, you have to give it a try.
Have you looked into Amethyst[1]? It's a tiling window manager for OS X. It's based on xmonad, not i3, but simply having something that tiles my windows is amazing, especially on larger Thunderbolt displays.
OSX has an unbeatable ability to zoom the full screen without losing mouse focus. No other OS I've tried supports this. Windows Magnifier comes close but it doesn't let me set focus to follow the mouse and it's awkward.
I use the full screen zoom and run Windows apps in virtualization. That's how important it is to me.
Ubuntu tried to make this work with Compiz a few years ago, and it was terrible as well. Slow and jerky.
But this is an absolute necessity for a low vision user like me. Got a Mac for my dad and he also can't live without it now.
Hopefully with Wayland coming around, this will all be simpler. The reference Wayland compositor (Weston) has a built in fullscreen zoom feature which is basically identical to OS X's (hold down key, scroll).
In fact, the default implementation in Weston is, better in my opinion, and also enabled by default. Instead of having to go to the edge of the screen to move the region, it moves the region with the cursor in the same position relative to the screen as the region. Of course, for those with dyslexia or some other psychovisual disability; it may be worthwhile to have an option to go the OS X route.
Thanks for the input, I'll maybe put it on the GNOME bugzilla if it isn't already there. :-)
The OSX zoom has the option to follow the mouse and is what I use (and require) so I can track what I'm reading. It's not default, but it exists and works incredibly well even under heavy graphics use. Seeing something like that work well on something other than OSX would be great. But every other attempt has bee spotty at best.
I look forward to seeing this work, but I worry about the hardware requirements that will be imposed.
I have a 2007 white macbook that zooms flawlessly. If I need a high-end video card to zoom as smoothly it will be a problem.
For some information, it is unfailingly buttery smooth even on integrated graphics hardware from one generation before Intel HD graphics. I.e. a lenovo Core Duo machine from 2006 I dug out of my closet the other month. This is all probably thanks to Wayland being properly composited to begin with; they just need to scan out part of the final framebuffer texture.
KDE 4 and 5 have a magnifier that follows the mouse and has worked just fine in any situation I've thrown at it. It's enabled by default, but you do have to assign keyboard shortcuts to "Kwin zoom in/out/restore-to-actual-size".
I use full-screen zoom in Ubuntu (14.04) and Macintosh everyday. In Ubuntu I can alt-tab between apps and the zoomed window will follow me to the top-most application, not so on the Mac which will switch apps but leave me viewing the wrong portion of the screen. Both will follow the mouse equally well. On the other hand I prefer the Mac's ctrl-scroll-up/down to zoom-in/out. On Ubuntu I use a couple of key-combinations as I haven't figured out how to do it with the mouse. I guess I'm suggesting to give Ubuntu another chance.
I wonder if you know TouchZoomDesktop. While it focus on touch input, it can be used with mouse/keyboard as well and offers easy zooming of the whole screen. I use it in presentations. http://www.lovesummertrue.com/touchzoomdesktop/en-us/
You're book is great for getting up to speed with tmux basics. The intro to tmuxinator was also pretty helpful.
One of the bigger things I think people miss is copying text into and out of tmux panes, including to the clipboard. This saves me a lot of time switching between windows often, especially using the vi keybindings. Although one thing I wish tmux did better was handling things like dividers.
I thought the book was great. It's a quick read, but easily increased what I could do with tmux. I can't think of much more it really needs. Maybe cover stuff like if-shell? The true-color patch might also be worth mention.
FYI, there's a slight bug with the xclip copy binding, but it's pretty easily fixed (bind C-c run "/usr/bin/tmux save-buffer - | /usr/bin/xclip -i -sel clipboard >/dev/null").
Just using tmux to get more than one terminal was really only a fraction of the stuff I could use it for. My terminal launches in XMonad use tmux by default now.
As far as the copy stuff, I'm talking about pipe or line dividers in terminal apps (e.g. mutt, ncmpcpp, etc... If whatever I'm trying to copy covers more than one line, tmux will copy over the divider which is painful.
I've had success with kwm[0], it works more like bspwm than i3 but has been the best tiling experience I've found on OS X. (And has focus follows mouse!!!!)
I bought your book too, thanks for writing it! I found it helpful and it got me started scripting tmux sessions. I plan to try tmuxinator but haven't yet.
For some reason I've ended up using a combination of i3, tmux, and Emacs window splitting, all at the same time. So three different programs that do something like window management, each with its own set of behaviors and keystrokes. This sounds like it should be a nightmare, but it's actually not that bad.
Others have mentioned the additional benefits of tmux beyond window management, but I also find that, much as I like i3, it's actually pretty hard to quickly and intuitively create, manipulate and delete window splits. Ie, top-bottom, side-by-side, rotate splits, stuff like that. The containers thing just seems unweildy, and just getting windows into the right containers always feels like a fight. I used to use StumpWM, and while that had its own problems, you could bang things next to each other for a second without having to really think about it.
Part of it is probably that I end up very rarely needing top-level window splitting, so I never get used to the keybindings. Splitting in the terminal and in Emacs takes care of most of my needs; I want to see different programs side by side no more than once every few weeks.
PS: There's a program called Sway that's basically a Wayland fork of i3. I keep it updated on my machine, and every once in a while amuse myself by using `startsway' instead of `startx'. It's coming along nicely, and you get that nice feeling of being retro and advanced at the same time. http://swaywm.org/
> So three different programs that do something like window management, each with its own set of behaviors and keystrokes.
I've found this a bit painful too but it gets better if you configure your window management keys with similar bindings. But I still do find it a bit annoying to have three levels of windowing (vim, tmux, bspwm) when I'd be happy with just one.
Tiling is the least useful thing that tmux does. Event the name (tmux) implies that it's core competency is something else entirely -- multiple sessions, kept open, switching between them, persisting, etc.
Exactly this. I open tmux on remote connections, maybe to panel (Altho scrolling through output in tmux sucks), but definitely in case I lose my connection while running a longer process.
My other favorite use is screen sharing without screen sharing (2 people connecting to the same session), super helpful when taking control over screens share is too slow due to network lag.
I'd agree that tiling is the less useful function, but the name refers to the tiling. Tmux is short for Terminal Multiplexer, in other words, it's a program that turns one terminal into multiple terminals, by way of tiling.
you'll see "screen is a full-screen window manager that
multiplexes a physical terminal between several processes", describing a piece of software that - at that point - didn't do any splitting or tiling.
OK, I said "tiling" instead of "window management", I should have been more precise but instead opted to use the same language the parent used. Coldtea claimed that the name tmux was a reference to "multiple sessions, kept open, switching between them, persisting", which I interpret as all the non-window-manager functionality — the attach/detach ability that makes tmux attractive for use on remote machines where the connection might die and you don't want to lose your processes.
"Multiple sessions, switching between them" is multiplexing. "Kept open, persisting" is orthogonal, I agree. The parent said "tiling" and I assume they were referring to, well, tiling - putting multiple non-overlapping windows on the screen at the same time by dividing up the available space.
That definition doesn't apply any better to the attach/detach functionality of tmux than the window management functionality, so you're going to have to use a more flexible definition than that for the term to ever apply to tmux.
A USB hub multiplexes a USB port by making it so that multiple USB devices can be connected to the same port and all pretend that they're the only ones connected to it.
The Ogg container format multiplexes a bitstream so that multiple timecoded media streams can be streamed through the same data channel and pretend that they're the only things going through it.
An preemptive-multitasking OS kernel multiplexes the CPU so that multiple processes can run on the cpu and all pretend that they're the only ones on it
A terminal multiplexer multiplexes the terminal so that multiple processes can output to the terminal and all pretend that they're the only ones using it.
That describes the window management functions of tmux.
>That definition doesn't apply any better to the attach/detach functionality of tmux than the window management functionality
It does apply with 100% to what it's meant to be applied: multiplexing terminal IO.
It has nothing to do with "window management". In fact it could also offer no window management at all, except for switching between sessions, which is was what it did initially.
Multiplexing is a well known, precise term, and terminal multiplexing as a technique existed before both tmux and its introduction of tiling (e.g. screen).
If you're really looking to do something strange, you could ditch the mouse all togeter. That's what I've done on one of my laptops.
For some reason when i first set it up the touchpad didn't work, and need some driver or something. Instead of fixing it like a normal person, I said to me self "just go with it".
I found a browser (qutebrowser) that works by using just the keyboard, and use tmux/vim and other terminal apps for everything else. The scrolling in the browser highlighted weird stuff (since the mouse cursor was always in the middle of the screen), but once I found a way to set the cursor to the top-left of the screen when X starts (a command in .xinitrc), no more issue.
I still have a minor issue every once and while. Sometimes i'll browse around and see a code snippit, or just some text I'd like to copy-paste, or a link with a url I'd like to copy and I'm not sure how. That's really been my only downside of going mouse-free.
This very useful info for me as well. I have periodic pains in my neck when using mouse for too much. I have been switching hands. But still. I much prefer emacs-like interface where I can operate with keyboard only.
And I like shells because I can connect from anywhere to the server where I do most dev and testing.
However, I recently started doing android development and and I am forced to leave my emacs and shells.
One reason is the running the emulator. It cannot run on remote x window sessions and I have to use mouse to access it.
The other reason is AndroidStudio. Although I use emacs with flymaker, as a newcomer to Android -- I find Android Studio's tools to do code refactoring, on the fly suggestions, detection of new versions of updates, very useful.
how do you copy from a terminal buffer to another window?
tmux allows selection without a mouse, but I agree with others that tmux tries to do too many things at the same time and I would therefore like to have a simple solution for this.
Since I can move the mouse I have no need for the pointer lock but I use unclutter a small utility that makes the mouse disappear when it's not used for a time.
For copying, qutebrowser has caret mode (I believe the hotkey is 'V') that lets you move the pointer with the keyboard and visually select and copy text as you would with vim.
Copying url's is done with the 'y' hotkey and a terminal emulator I use (termite) has a hotkey for finding and opening urls from the terminal.
I use tmux as a persistent terminal multiplexor on a higher-than-preferred latency connection. I'm worried that i3 over VNC would be even slower, but I'm willing to give it a shot. Do you use i3 on a local or a remote Linux machine?
It depends on whether or not vnc is bandwidth limited on your link. A high bandwidth, high-latency connection shouldn't feel significanlty different over vnc or a terminal, but if your high-latency is due to being bandwith-limited, vnc will be much worse.
i3 is your tiled window manager. You just open your terminal and connect on ssh as usual. i3 wouldn't have anything to do with your connection to the ssh session.
I share the same feeling (as for the splitting feature alone). I also love the minimalism and the fact that there is no screen estate waste(1 windows takes 100% of the screen, 2 takes 50% each, etc...).
Since I switched to i3 I completely stopped to use tmux.
/r/unixporn is full of i3 screenshot and config to learn from i would encourage new users to look at it.
> So if you like tmux and you're on Linux, I'd strongly recommend giving i3, awesome, or some other TWM a try.
I've heard great things about i3 & awesome, but haven't used them myself. I've been using stumpwm for several years now, and I just love it. There's nothing like being able to connect to one's WM in a SLIME session and recompile portions of it while it's running!
I use i3 for tiling graphical windows, but I use tmux for tiling and multiplexing terminal panes. The reason I prefer using tmux for terminal stuff is so that I only ever need one terminal window open, I can use the same tool when connected to remote machines with only one connection, etc.
The benefit of i3, though, is that a terminal is just another window, and the direct navigation happens between windows. I can jump directly from a terminal to a browser or IDE because the construct is the same for all of them.
What about saving sessions? With Tmux/Screen, when I close the window, the session can be saved, meaning when I come back tomorrow, everything is right where I left it.
My main complain about tmux is that it messes with my terminal emulator scroll buffer. I like to use a mouse to scroll my terminal emulator. For example I can do `cat file` and then scroll around. If file is huge, `less` is better, of course, but for most things terminal scrolling is perfect. But `tmux` and `screen` completely ruin that experience. I know that they have their own scrollbuffer and scroll mode and all that, but I've found that perfect user experience for me is to blend GUI approach and text mode approach instead of replacing it.
I have my tmux set up as you describe, it's easy to do.
In newer versions of tmux, you just add 'set -g mouse on' to your ~/.tmux.conf. I also have copy mode set to use vi keybindings, and I can yank to the system clipboard.
+1. Scrollback used to be one of my gripes as well, but it now works well under tmux.
I like to have a single key binding to toggle mouse on/off, so I found a clever (although hacky) way reading someone's .tmux.conf, and have used it ever since:
# toggle mouse
bind m run "cut -c3- ~/.tmux.conf | sh -s toggle_mouse"
# toggle_mouse() {
# old=$(tmux show -g -w | grep mode-mouse | cut -d' ' -f2)
# new=""
#
# if [ "$old" = "on" ] ; then
# new="off"
# else
# new="on"
# fi
#
# tmux set -g mode-mouse $new \;\
# set -g mouse-resize-pane $new \;\
# set -g mouse-select-pane $new \;\
# set -g mouse-select-window $new \;\
# display "mouse: $new"
# }
I love Emacs, and I've used it for years, but this is an insanely unfair summary.
NeoVim can be trivially extended in any language. They're putting a lot of effort into making sure that the msgpack protocol supports basically everything. This means that, unlike in Emacs, it's straightforward to write extensions in whatever language is best for the job--something really, really important when it comes to language bindings themselves, which is probably the main thing I frequently find myself extending in Emacs in the first place. So saying it's written in a worse language seems bizarre to me.
NeoVim also, unlike Emacs, is cleanly split into a frontend and a backend so that its editing core can be used in different contexts. Combined with the above, that means you will eventually (hopefully) be able to get "the real" NeoVim in lots of apps, rather than either a kind of broken "Emacs mode" (like in IntelliJ, NetBeans, and Emacs) or having to do this weird "save a text blob to disk, open in Emacs, wait for it to be closed, reload in the app" dance. Already, this separation has allowed the creation of NyaoVim (https://github.com/rhysd/NyaoVim), a browser-based front-end that I could imagine being incredibly useful for remote editing, whether in a cloud-like environment (e.g. Cloud9, CodeAnywhere) or on a remote server.
Emacs is great. NeoVim is also heading in an excellent direction. You don't have to give it a chance, but you also don't need to be so dismissive.
* it's straightforward to write extensions in whatever language is best for the job--something really*
Although this is great, this sounds like it can cause a lot fragmentation, everyone writing plugins with their favorite language and consumers having to deal with the pain of multiple runtimes.
Is there a preferred language endorsed by the project?
I use both a lua-configured mail-client, and a lisp-configured emacs. Of the two they're both powerful and extensible, but the Lua config feels more natural to me.
I've used Vim exclusively for 12 years. Over those 12 years I tried switching to Emacs no fewer than 5 times. The longest it stuck was 3 months, and I still felt a huge weight lift from my shoulders when I switched back to Vim.
6 months ago I switched to spacemacs and haven't looked back since.
My story is similar to yours. Spacemacs really is the best of both worlds: the Emacs ecosystem of packages combined with good defaults and without carpal-tunnel inducing keybindings.
Thank you for this! I'm trying it now. It feels much more familiar than my previous attempts at using evil-mode, and seems to work nicely even in a terminal window.
I just tried evil mode a few days ago and felt blown away by it. May I ask what problems you ran into? I believe you, and I'm trying to find out what to watch out for.
My problem was mucking around with regular emacs stuff whenever I was trying to get into evil-mode or out of emacs. 17 years of vim muscle-memory trips me up every time I try to recall the magic combination of keys that does what I want. I never made it far enough to use emacs to modify my emacs configuration and enable evil-mode by default. Spacemacs seems to make this a lot easier by setting up evil-mode for you. It also replaces all of the control-this and meta-that with hitting the spacebar in while you're in command mode.
Yeah, eshell is great, and emacs "windows" are pretty excellent panes. And it's so useful that buffers are independent of the windows they're in. I've been writing Clojure full time in Emacs with Cider and paredit for a little over 3 years now, and I feel like I'm more productive than ever before.
this said as much as I've been using emacs since forever (more recently also with evil-mode occasionally) I am really happy to see neovim gain better terminal support, because my usage of emacs skyrocketed when I discovered I could use it as a terminal replacement, and I am sure that vim users will take advantage the same way
I have actually investigated running emacs -nw inside neovim terminal (as a reverse-alternative to evil-mode, because I doubt org-mode will become available in neovim any time soon), but last time I tried it it wasn't working that great due to meta etc. not being passed successfully to the terminal, there was an issue open on this so it probably will be fixed at some point
neovim doesn't have much on top of what vim has; it has async plugins and a terminal, in a lot less code than vim is constructed from, and everything else is external. It has less testing because it's been around less time and this would be an equally pointless criticism of any new piece of software. Your last thing was just an opinion that one may or may not agree with.
If your primary use wasn't the background/attach feature, sure this will work as will many other mechanism. I know like many users my main motivation is not losing the terminal session when (not if) X or Wayland crashes.
In fact I'd go so far as to say if you aren't using it for the attach/detach functionality why on earth would you bother? I'm not seeing how using tmux beats "Just open another terminal" which is the absolute minimum.
Surely anyone doing dev work is using an editor that supports tabbing and in-editor consoles a la emacs.
Most of the other features that both screen and tmux include give me reason enough not to use either one. If you're just in it for the detachability, see dtach. <http://dtach.sourceforge.net/>
tmux and screen make it comfortable to manage multiple sessions. That's why I don't just use dtach. Having one session with multiple buffers/windows is easier to manage than one file for each dtach'ed program. Basically, I'd have to script my way out of dtach's bare bones session management feature set.
I don't really use tmux's or screen's split functionality, and if I did I'd probably start using http://www.brain-dump.org/projects/dvtm/. Hmm, abduco seems like dtach on stereoids and is thankfully separate from dvtm and required for detaching dvtwm sessions. Maybe I should give that a try.
I'm significantly more productive with tmux + autossh. I autossh into a single server from which I have about 30 SSH sessions open - organized by environment (tmux sessions) and host (tmux windows). The windows have the name of the host. I rarely use my number keys - I just shift-left arrow or shift-right arrow to the previous/next window since jumping around is so quick.
tmux-resurrect is awesome too - if the server I autossh into reboots, I can just restore all my sessions and windows and it re-sshs into the 30 hosts.
I have almost this exact same setup, except I use tmuxinator instead of tmux-resurrect. Honestly tmux-resurrect looks like it's the better solution; I just haven't bothered trying it out.
Simply replacing tmux with the same inside NeoVim doesn't feel like a win to me. Tmux is very powerful (providing for decent nesting with remote servers), and until NeoVim reaches Emacs levels of configurability and extensibility, I don't see it being a viable replacement anytime soon.
Yeah, I can't see how I'd replace persistent sessions on remote servers with this. I could see it working as a quick and dirty way to switch between my editor and command line, but I've always been a bit skeptical of terminals running under editors (they tend to lock up the whole process the moment you have heavy logging.)
Personally I've had this combo segfault a couple of times in the past year or so, which never happened with screen or tmux. I've been using dvtm+dtach for a while now and had no problems.
abduco also used to leave cruft around if it didn't shut down cleanly (e.g. laptop battery cutting out), which would confuse it when next starting up (trying to attach to a non-existent session). I saw some entries in the changelog which might have fixed this, but I've had no problems from dtach so not felt a reason to switch back.
As the primary author of these tools, please report core dumps/stack traces of the crashes (if you get hold of them). At least for my use cases, the current git versions seem to be stable ...
Having said that, if I ever find the time I would like to overhaul/replace dvtm's terminal emulation component.
The crashes I was referring to were seg faults, which happened seemingly at random, several months apart. If I had more useful/reproducible info I would've filed a bug report :(
Turns out you can use the same navigational keybindings to move around nvim splits and tmux splits, so that moving between the two programs is a sinch. This is what I use.
Does neovim have session persistence for those embedded terminals? Can you share a session with other people as easily for pair programming/debugging?
I'm not familiar with neovim's terminal emulator. What happens when I press CtrlX-CtrlE? Is it similar to a normal terminal with readline set to vi binding?
No, if you're after session persistence or sharing ala tmux, that's right in the sweet spot of what tmux does well and neovim's :term mode isn't designed form.
It's quite possible that we'll see those features in the future, what with neovim's separate frontend vs. backend architecture.
If your workflow involves a) more than one computer and b) usage of the terminal (surely describing most developers), then tmux attach/detach is easily one of the most awesome things since vim itself.
This depends a lot on your workflow. Sometimes I've lived by screen/tmux session management, but more recently I almost never need it. Yet tmux+vim is a vital daily part of my workflow. In its current role, tmux serves primarily as a window manager.
It's worth noting that I'm using other means to keep my state synced between my working environments (place) or between working sessions (time). Version control is part of that (such as private git branches), good environment automation is part (via Vagrant + provisioning, packagers like npm, etc.), and automated vim session save/restore is another part of that. For example, if a vim dies or if I quit, my entire session state is completely restored for that project when I start vim in that directory again. That all provides quite a lot of what I'd traditionally depend on tmux for.
All that trouble for nothing. I use xterm and control-z, and fg, one terminal window. If I need to work from more computers than one I use a screen instance that I can detach/attach from the computer happen to be at.
it's bog-standard and readily available on most platforms. no real need for split screen, either fullscreen web on one workspace and terminal on other or side by side if working on computer with big screen.
JOE has pop-up terminal emulators: hit F1 - F4 to bring up one of four terminals, or flip between them (like Alt-Fn on Linux). It's nice, you don't have to exit the editor to read a man page. But there is more...
JOE tracks the current directory of each of these emulators, so they are great for navigation: use cd and grep to find something to edit, then type 'joe filename' within the terminal emulator to replace the terminal emulator with the requested file.
Also you can play games with regions and the compiler and grep parsers. This, from one of the terminal emulators:
parse grep -n main *.c
will find all of the .c files containing main, mark the grep command's output as a region, and use the editor's grep parser to load the list of file locations into the editor. So then you can step forwards or backwards through the locations with Esc = and Esc - as you would step through compiler error messages.
(Use 'parserr' instead of 'parse' to parse compiler error messages: type 'parserr make')
You can control the editor by writing programs which send editor macros to JOE: just echo Esc { macro } to the editor. JOE runs a shell startup file /etc/joe/shell.sh to provide some aliases. 'joe' and 'parse' are two of the aliases from shell.sh.
I can't give up tmux because it's what we use to remote pair at work. At the very least our team worked out some good keyboard shortcuts: C-a leaders with caps mapped onto Ctrl, VIM/Tmux setups lifted from YADR so when you hit C-h/j/k/l you can jump through VIM windows and tmux panes seamlessly, etc. With some work tmux is awesome and we mostly just copy/paste links over hipchat if we're looking at documentation.
I also tried neovims terminal support and I must say I really like it. The reason is that you have a consistent way to mark and copy text from your terminal buffer(it basically works like in the editor).
I had some other issues with nvim, which why I'm not yet settled on using it. I also like abduco for connection management.I'm currently using i3wm and a combination of some other tools such as parcelite to make sure that the copy and paste buffers are synchronized. I'm still looking for a simple way to be able to select something from the terminal buffer and copy it to somewhere else without the need of some complicated key bindings (e.g. not using screen or tmux). neovims terminal works well for this use case.
I don't have the need to run a complicated dev enviroment using only terminal windows on some remote server. I would rather run i3wm and use NX to connect (its fast enough) if I had that use case.
the amount of levels of stacking for work organization is pretty scary. Its as if people spend more time trying to organize than actually working.
I use tmux for simple stuff that needs a "detached terminal", not work organization. multiple terms, the wm and the editor buffers is already more than i'd ever ask for.
I have been using i3, tmux, vim's conque, ... haven't used neovim's conque yet so I can't comment on it, but here's my experience:
* i3 is fantastic for 90% of your tiling window activities: stacking a LOT of windows on the same screen without any problem, its different modes (stacked, windowed, tabbed) are ingenious, it makes it possible to use minimal number of keystrokes to navigate between any arbitrary windows.
The ugly side is that once you've set up your screen with the windows you want, you probably want to keep them like that, while i3 allows you to shift your windows around it gets a bit messy (how do I group these windows together under a different layout?). Also, on Ubuntu, i3 doesn't have the nice "stuff" of other DE, the worst part is that windows don't carry over gnome themes properly and there are bugs with some applications (chrome). Also integrating an "Open another terminal in the current directory" is a headache.
* tmux is great for everything terminal related, it's not as good as i3, but it does its job well (splitting, windowing, saving sessions). It has a few interesting features that makes the move to i3 difficult, such as 1) opening another terminal in the same directory 2) scrollback with vim keys (so that you can run a command, do a reverse search on the output, and copy part of it out) and finally 3) sending the same keystroke to multiple terminals (handy when ssh'ing to multiple hosts for testing).
The downsides is that tmux doesn't seem to handle the console all that well (editing in the middle of a bash command kind of breaks on my machine) and it can be annoying to make a script that works with tmux (since it breaks the process parent/child tree, this probably won't affect anyone though)
* I have tried vim's conque plugin, but the terminal freezes from time to time. I'm not sure if neovim's plugin is gonna have the same issue.
Overall I don't think there's a single piece of software that handles everything completely satisfactory yet. i've been satisfied with tmux for a long time, now making the move to i3 (it's everything I never knew I wanted), despite its several issues I think I'm gonna stick with it for a long time.
neovim's terminal is not a plugin, is baked in and is a proper terminal emulator, based on the libvterm library. So, it shouldn't have the same issue, it makes use of the async features in neovim.
Thanks for the explanation. I actually just downloaded neovim to try out this feature, and I must say that with neovim-remote this is incredible. I think i3 and neovim's terminal mode is about as close as I can get to an ideal desktop setup. Having a terminal that can send arbitrary keystrokes to your editor open up endless possibilities.
I saw a neovim video[0] where the operator opened a terminal and then launched emacs in it. Can one now (by keyboard only), copy/cut from the emacs terminal and paste into the neovim screen? That's one of the nice things about tmux, where I can run a cmd, copy from the backbuffer, and paste into an editor to (e.g.) mail off the context for a bug report.
Here is my set up: I run emacs in server mode doing most of my work w/ an X11 emacs client, and eshell when I need a Unix prompt. As much as I like eshell there are many scenarios where I prefer zsh so I run zsh in tmux and invoke a non-X11 emacs (-nw) client within tmux to go back and forth (copy/paste whatnot) between emacs and zsh. Repetitive strain problems aside, I am generally pretty happy with this setup.
I still have problems with the ssh agent when running tmux. No amount of hacks or symlinking sockets everywhere seems to give me a reliable (re)connection to the agent when detaching and reattaching to tmux across machines and ssh sessions.
This is very specific to people that already know and use vim, but I agree. Once I learned about neoterm I have switched over to an instance of neovim defaulted to term://zsh as my initial shell.
while we're talking about tmux, when will it gain screen's flow control (not tty flow control you can enable/disable), so that something like 'tar xfv linux-4.5.tar.xz' won't lock up tmux anymore. This works smoothly in screen but breaks tmux.
That depends on your goal. If you just want to log in and work remotely in neovim, sure. But neovim won't provide tmux's feature of being able to reattach to a session in the face of unreliable connections.
That said, most of the time I use tmux is on localhost as a tiling window manager for terminal-based work. In those cases, it's very rare that I use tmux session recovery, so there's merit to simplifying the stack by dropping tmux.
Even if you did adopt the "nvim multiplexer" approach for local work, you could still use it remotely inside of one simple tmux pane. (i.e. ignore all features of tmux except for session management.)
I don't think so. This is why I primarily still use tmux, although I've recently been messing around with i3 and AwesomeWM on my linux box, which is superior to tmux. DTVM seems to be gaining ground, it's just not quite as feature rich as tmux.
I fail to see what he is saying is more efficient by cutting off tmux? When switching from tmux to another pane seems to be exactly the same as switching inside of neovim? I am missing the whole point, and missing something.
Just to know. why did you mention proudly? I don't use it either, but i thought it had gotten pretty stable over time and has very few issues. What problems do you see using neovim?
I just don't like the way this fork happened. I used Vim for 20 years and it really made me mad how Vim was treated. It reminded me of the FFmpeg vs Libav.
Most of the claims from neovim seem over the top and off from factual i.e. vim base code is so bad it is unreliable.
> Every other aspect of Vim is irredeemable. The codebase is atrocious. The plugin API is cumbersome and restrictive. The dev community is apathetic. The benevolent dictator is averse to change. There is no chance of fixing these problems. http://usevim.com/2015/01/16/neovim-better/
Most of the claims from neovim seem over the top and off from factual i.e. vim base code is so bad it is unreliable.
To be fair, the one example you give is from a person not directly (to my knowledge) associated with the neovim fork. There was more than a bit of discontent, I think, at the slow rate of progress Vim was making compared to more modern options. I've been using Vim about as long as you have, and I have to say that I welcome the options neovim brings to my favourite editor.
I suppose it's impossible to have any fork of such a well-worn, fundamental piece of software without some feeling the need to be partisan. I have to say, though, that Mr Arruda has regularly conducted himself with a great deal of courtesy and professionalism, at least in every instance I have seen. I'm quite happy to be throwing his team a few bucks every month.
Here was Bram Moolenaar (Vim foudner/Maintainer) The guy didn't take money for the job but asked people to donate money to African Orphans and they do a fundraiser to cut the man off?
"It's going to be an awful lot of work, with the result that not all
systems will be supported, new bugs introduced and what's the gain
for the end user exactly?
I have to say, the links you post don't really do much to bolster your case. Was there something particularly damning in the first link that I missed?
I'm also a little unclear on what Ugandan fundraising has to do with this. Does taking money for Vim development preclude charity? After all, Bram himself took donations for his work on Vim for some time. From the Vim.org sponsor page (http://www.vim.org/sponsor):
Fixing bugs and adding new features takes a lot of effort. To show your appreciation for the work and motivate Bram and others to continue working on Vim please send a donation.
Since Bram is back to a paid job the money will now (after March 2006) be used to help children in Uganda. This is the charity recommended by Vim's author. The money is used for a children centre in the south of Uganda, where AIDS has caused many victims. But at the same time donations increase Bram's motivation to keep working on Vim!
So saying Vim is bad because it doesn't do what it was intended and take away potential funding and mindshare with vim to do a "refactoring." They were saying make Vim good like emacs? Vim vs Emacs will never be settled and this is such a waste. Vim works and does great things. If you want to do something else entirely besides keeping vim scripts and the UI call it something else.
Not sure "how" a fork happens is interesting; do you mean why it happened? This has been stated before.
I didn't think anyone disputed those statements (end of your post). Why did neovim start if they weren't true? You'd just submit code fixes etc and get them accepted, right? Did this not happen? If async support was already in vim why is there so much activity on async plugins for neovim now?
It doesn't really matter what you think of how vim was treated; i've seen cordial conversation between the main dev of both projects suggesting both parties benefit from neovim, and at the end of the day users and potential vim/neovim developers can only benefit what with them both continuing to be open source projects.
> If async support was already in vim why is there so much activity on async plugins for neovim now?
Because people like to build a new X to replace the old x. This was MUCH more about code not being accepted into Vim and personalities then code, in my opinion.
It's also pretty trivial to get some nice window arrangements so that I can quickly move to relevant parts of the code for whatever I'm working on.
I guess the major trade-off is that there aren't any menus for accessing functionality, but I personally consider that a win because I end up being forced to learn how to manage everything at the lowest config level, usually editing text files. This makes it vastly easier to script things when I realize I've been making the same changes over and over.
So if you like tmux and you're on Linux, I'd strongly recommend giving i3, awesome, or some other TWM a try.