2 ms·
Another option would be to split screen's roles of "terminal multiplexer" and "terminal detacher" into two programs: dvtm and abduco, respectively. I find that
by tomjakubowski 7y ago
Another option would be to split screen's roles of "terminal multiplexer" and "terminal detacher" into two programs: dvtm and abduco, respectively. I find that approach more flexible than screen/tmux, and it works better spanning work environments where I might or might not have tabs and splits built in to my window manager or terminal emulator. It's also nice to not have to give up C-a or C-b keybindings when I don't need multiplexing (abduco uses just one key binding, and I think you could get away without it).
abduco: http://www.brain-dump.org/projects/abduco/ http://www.brain-dump.org/projects/abduco/
dvtm: http://www.brain-dump.org/projects/dvtm/ http://www.brain-dump.org/projects/dvtm/
- rramadass 7y agoBetter; use dvtm within Screen. This is what i do; one Screen session (fullscreen size) on my main dev box with each Screen window running its own dvtm instance. Thus each Screen window becomes a "workspace" (if needed, connected to a remote host) with dvtm-managed multiple tiles/shells. Flexible and not too complicated with all the power of Screen and the simplicity of dvtm. In fact, i use this setup even when working on my local machine. Throw in vim for the editor and you have a simple and standard setup which you can carry with you everywhere.
- tomjakubowski 7y agoI appreciate the simplicity of abduco when saving sessions of already TUI-intensive programs like MUD or IRC clients.
- ansible 7y agoWhen starting my GNU Screen journey 10-ish years ago, I immediately switched the meta key to Ctrl-K, which I had never used for anything in any app up to that point.