
Show HN: Terminal Multiplexer Inspired by I3 - aaronjanse
https://github.com/aaronjanse/3mux
======
aaronjanse
Hey HN,

I'm a long-time user of i3 (now sway). I wrote this tool to provide the
elegance of i3 to terminal users everywhere, especially for people like myself
who sometimes use a non-i3 wm or no window manager at all (e.g. when testing
code on a bare-bones raspberry pi).

Cheers!

~~~
krat0sprakhar
Looks awesome, thanks for sharing! I've been using Byoyu[0] which has a
similar goal, but I'm keen on trying out. Even though I've been a long-time
tmux user, as a developer I don't even know where I would start if I wanted to
build my own terminal multiplexer. Can you share some resources etc on what
could a good starting point if I want to explore this as a side-project?

[0] [https://www.byobu.org/](https://www.byobu.org/)

~~~
aaronjanse
My understanding is that a terminal multiplexer consists of three parts: 1\.
Managing shells and windows 2\. Parsing the ECMA-35/ECMA-48 escape/control
sequences 3\. Rendering the shells' parsed output within their window
boundaries

> Can you share some resources etc on what could a good starting point if I
> want to explore this as a side-project?

I'm still looking for resources myself. Check out JdeBP's comment for some
good information
[https://news.ycombinator.com/item?id=22847168](https://news.ycombinator.com/item?id=22847168)

------
nmarriott
This [https://github.com/jabirali/tmux-
tilish](https://github.com/jabirali/tmux-tilish) is a different solution with
a similar goal - to make tmux work more like a tiling WM.

~~~
jabirali
Hey, thanks for linking to my project! :)

For other people that might be reading: the main difference between these
projects is that 3mux is a tmux _replacement_ , while tilish is a tmux
_plugin_. Thus, 3mux is a much larger and more complex undertaking, but you
can more easily get tilish up and running anywhere (just copy over a
tmux.conf).

But I believe both have the same motivation: "porting" the i3wm user
experience and keybindings to terminals. 3mux is also very cool, and I'll be
keeping an eye on it myself :).

If you try out tilish, I'd be happy to receive any feedback!

------
snidane
This looks awesome!

The modifier key seems to be Alt, which is also default on desktop i3 windows
manager. I wonder if it's going to interfere - eg. pressing Alt+Enter will
simultaneously open new window both in multiplexer and on my desktop?

~~~
e12e
I think the "escape"-design og screen/tmux is likely better for terminal
multiplexing - other "hot-keys" is too likely to collide with terminal
programs (never mind window managers/desktops)?

I suppose "super"/"windows"-key combos might be a bit safe from terminal
applications - otoh they're likely to collide with window managers...

~~~
kbumsik
> I suppose "super"/"windows"-key combos might be a bit safe from terminal
> applications - otoh they're likely to collide with window managers...

AFAIK terminal usually doesn't support super/windows key at all.

------
alpaca128
My favorite is dvtm. The main reason is how it handles scrolling and selecting
content: by opening the buffer in Vim. This is really powerful because it also
lets me do anything Vim does, including saving parts of a command's output
directly to a file, after cutting out irrelevant parts.

But this looks like a great project too - using WM-like shortcuts in a
terminal multiplexer works really well.

------
stragies
How about the memory usage?

Can you (easily) nest 3mux like tmux with (auto-)grouped sessions to produce a
(max) 9x9 "grid" of windows to organize your remote hosts, and their windows
into an easily accessible structure. (I use this to be able to reach any
window in any other terminal window on any host with max 4 keypresses)

Why choose Go? Just curious.

~~~
aaronjanse
> How about the memory usage?

The biggest thing stored by 3mux should be the state of the terminal screen,
so memory usage should be negligible.

> Can you (easily) nest 3mux like tmux with (auto-)grouped sessions to produce
> a (max) 9x9 "grid" of windows to organize your remote hosts, and their
> windows into an easily accessible structure. (I use this to be able to reach
> any window in any other terminal window on any host with max 4 keypresses)

This is an awfully specific request. However, I plan to soon add support for
workspaces, which should give the user access to, for example, 40 panes within
2 keypresses, given a hypothetical 10 workspaces and 4 panes per workspace.

> Why choose Go? Just curious.

Good question! I chose Go for its go routines and channels. I somewhat wish I
used Rust simply because of its elegance. 3mux's performance bottleneck right
now is completely IO, so I don't think moving to Rust would make a noticeable
difference to the end user apart from the installation process.

~~~
stragies
Thank you for replying!

I described my workflow, because since I discovered automatically grouped
sessions on TMUX, I'd never want to use a terminal multiplexer without that,
or comparable functionality.

What I do:

* Open new terminal with a hot-key

* This terminal automatically joins my local (default) session group

* All windows in this session group are now available

* Most windows connect to remote TMUXs

* With CTRL+ 4 keypresses I can navigate to any preexisting window/session, or create a new one locally (or on a remote host)

* After using the window, either i close the terminal, and/or the window, depending on if i want to keep this one.

* On the remote end, people can join my sessions, and can independently of me navigate in the remote window space.

* if I need to concurrently see two (probably different) windows of my local/remote window grid, I just open/auto-attach another terminal.

* the above makes it easy to "place another live tmux view" on a screen different than my main screen, for presentation, or teaching purposes.

Everybody (who previously used tmux in non-grouped mode) I've shown/explained
this setup to, has setup their environment just like it afterwards.

Thanks for the other info too :)

------
AndreasBackx
I have been thinking about something like this as well. My idea however was to
integrate sway/i3 and your terminal of preference (kitty here) with your
server over ssh or using eternal terminal. My idea was to simply open new
terminal windows already attached to the session and remember their location.
I haven't thought about it thoroughly, but this seems like a good alternative
for the time being. Might give it a shot on Tuesday at work :)

------
tveyben
Excellent!!! I think this is _exactly_ what I have been wishing for (fro quite
some time now)!

I am not quite ready to make the switch to i3 as a WM, (I'm still fairly 'new'
in the Ubuntu world, so still need the GUI to help me find settings that I
don't know the name of thus how to access via a CLI) this brings me all the
great features for my terminal (just like you stated).

This is now the first item on my TODO list for testing new SW :-)

~~~
reachtarunhere
You should give [https://regolith-linux.org/](https://regolith-linux.org/) a
try. It's a Ubuntu based distro with i3 as WM. They have polished a few things
here and there so you have icons for WiFi and easy access to settings.

~~~
cptnapalm
Just used the PPA. Looks very nice. Has some very nice defaults. Super-Shift-?
to get the keybinds was a great idea. I did hit one snag: I can't figure out
how to run any actual programs. With the remapping of Super-d to pull up
display settings, I am not seeing anything that will pop up an equivalent to
dmenu.

~~~
nurbel
it should be on super-space. and super-enter creates an new terminal.

~~~
cptnapalm
I saw that on the web page. All I needed to know, minus how to get the bar on
the top. The Action|Keybinding menu that comes up on first launch is simply
too tall to fit on my laptop screen; the most important section Launch is off
screen if I don't close several of the others. All in all, though, I'm very
impressed with it.

~~~
reachtarunhere
Glad that your enjoying it. Just add these lines to ~/.config/i3/config and
reset. That should get the bar on the top.

    
    
      # Start i3bar to display a workspace bar
      bar {
        position top
        status_command i3status
      }

------
JdeBP
The quality of a terminal multiplexor is is in part determined by the quality
of the terminal emulation. Unfortunately, this one leaves a lot out.

* The ECMA-35/ECMA-48 escape sequence and control sequence processing is wrong. It is a common error made by people who have read escape sequence lists, but the actual way to process output to a terminal involves a proper state machine, which handles _all_ sequences, even unknown private ones. ECMA-35 and ECMA-48 define ranges of Intermediate, Parameter, and Final characters. One needs to handle the succession of such characters fully, otherwise one ends up like Konsole, which breaks when given some control sequences, erroneously displaying part of the control sequence as text.

* In that same vein, the actual code for CSI is U+009B. The ESC plus open square bracket sequence is a 7-bit alias, from when the world was not 8-bit clean. That 7-bit world hasn't been the case since the late 1970s. There is a whole range of control characters from U+0080 to U+009F.

* Continuing in that vein, the correct terminator for OSC is ST, U+009C. There are moreover rules about ESC, CAN, SUB, CSI, OSC, PM, DSC, and so forth occurring partway through control sequences.

* Even more: The actual code for Reverse Index is U+008D. The ESC plus M sequence is but another 7-bit alias. For best results, translate the _entire_ set of 7-bit aliases into the actual C1 control characters and handle them in their true 8-bit clean forms. It's a simple addition calcuation. It's silly that people write terminal emulators in the 21st century that are decades past the years of not being 8-bit clean, and that handle Unicode, that nonetheless still recognise only the 7-bit alias forms of escape and control sequences as if we still live in a 7-bit world.

* Just don't work from the console_codes manual page for Linux. At all. That documents an idiosyncratic, very limited, and in some famous places _downright wrong_ terminal emulator. I set out explicitly to provide the feature set of that terminal emulator. _You_ should not have to. Use ECMA-48, ECMA-35, and ITU T.416.

* Several years ago people started coming around to the reality that SGR 38 and SGR 48 were supposed to take colon-separated _sub_ parameters, not semicolon-separated parameters. The world has been gradually rectifying an almost 30-year-old error. The correct source of information is ITU T.416, _not Wikipedia_.

* On the positive side, note that this terminal emulator does not have zero meaning default. Zero means zero. This is a good thing. Zero meaning default went away entirely in 1991, and was superseded in 1986. But note that various test programs haven't progressed past 1976. Particularly, note that several of the tests in vttest will fail when zero means zero. (I myself just implemented Mode 22 for getting vttest to work, even though technically Mode 22 has been deprecated since 1991.)

* Although many modern terminal emulators agree on not providing blink any more, the _reason for_ not supporting blink (wasted battery power continually blinking parts of a framebuffer) does not apply to something that renders onto an outer terminal rather than onto a GUI. Let the outer terminal emulator make this decision.

* A lack of reverse video is a shame, and there isn't a reason for not having it represented internally at least. However, it is non-trivial to pass through. Only Konsole really gets it right, and some terminal emulators get it profoundly wrong. Interix cannot turn only it off, (U)RXVT decides to do something completely other than reverse video sometimes, and PuTTY erases using the wrong colour when reverse video is on.

* In that vein, note that several terminal emulators support subparameters to SGR 4 nowadays, giving different underline styles, including curly (SGR 4:3) and dotted (SGR 4:4) amongst others. Mine does, as does kitty (not KiTTY). The Windows Terminal people have it on their to-do list.

* You'll find that there are still outer terminals that do not support SGR 38:5/SGR 48:5 and there are still outer terminals that do not support SGR 38:2/SGR 48:2. One actually has to translate colour systems.

* "hard refresh" misses out a lot that a full-screen TUI program needs to do, from unsetting origin mode and margins, through resetting the cursor shape, to turning off automatic right margin and erase colour mode.

* People _will_ complain about lack of DECSCUSR support. VIM, NeoVIM, and others do make use of it, including several XTerm extensions to it. And this _will_ highlight the aforementioned deficiciencies in the control/escape sequence processing model. DECSCUSR is a CSI-begun control sequence with U+0020 as an intermediate character and U+0071 as the final character.

* People will complain about lack of scrolling region support, too. Full-screen TUI applications that present windows/panes redraw scrolls significantly less efficiently without it.

* Not handling ISO 2022 graphic sets is actually a feature, nowadays. It's a feature of Mosh (q.v.). But again the partial escape sequence processing won't handle this properly. There are several Intermediate characters involved in the G0/G1/G2/G3 designation escape sequences, not solely U+0028. The state machine for decoding them needs to correctly decode all of the Intermediate, Parameter, and Final characters of such a sequence, too.

* Unfortunately, for full keyboard support -- particularly for (U)RXVT, the SCO Console (and derivatives), and Interix as the outer terminal -- one has to add non-standard extensions to ECMA-48. Handling function keys sent from URXVT is particularly egregious. (I myself actually use a patched URXVT, to remedy a couple of its more extreme problems, including a hardwired assumption of 10 function keys.)

* You really don't want to ask the outer terminal for anything other than the new ECMA-48-conformant mouse reports (DEC Private Mode 1006) or the old DEC Locator reports. The other report styles (1005 and 1015) have significant problems. Vanilla URXVT is deficient in this regard, unfortunately.

* It's actually ECMA-48 in _both_ directions, outer terminal _input_ in addition to outer terminal _output_. DECFNK et al are valid ECMA-48 control sequences, with parameters and a final character. It is a very common error to mishandle them with pattern matching and fixed buffer offsets, but it is an error nonetheless. It's an error that becomes very apparent whey trying to implement modifier recognition. Learn from the pain that users have configuring the recognition of modifiers in pattern-matching systems like GNU Readline, editline, or ZLE. Make it parse ECMA-48 properly, so that parameter recognition in input control sequences _just works_.

* Deferred wrap should be cancelled by cursor motions.

* Tab stops are set by CTC and HTS. They should not be fixed at every 8 columns.

* Passing the TERM environment variable straight through, whilst otherwise ignoring it, is going to cause no end of problems.

~~~
aaronjanse
Thank you so much for this very helpful list. I'll integrate its suggestions
into 3mux.

~~~
JdeBP
[https://unix.stackexchange.com/a/289871/5132](https://unix.stackexchange.com/a/289871/5132)
might help too.

------
kentt
Is this mostly for using w/o i3? I feel like I'm not missing much by using
regular terminal windows and letting i3 manage those windows, but I'd love to
find out I'm missing something awesome.

~~~
aaronjanse
> Is this mostly for using w/o i3?

Yep! I can't think of anything magical that could arise from usage with i3,
but I'm open to ideas.

------
hestefisk
This is awesome. Thank you. Speaking of i3 I would love to use it but it
doesn’t really work well on a 4K screen. Any thoughts on how to make it work?

~~~
rwha
Xft.dpi: 192 in ~/.Xresources should do it for most things. I know chromium
and firefox do now. However I couldn't get (u)rxvt to scale. The i3 docs [0]
also state a font that scales is needed (e.g., *.font: pango:somefont in
~/.Xresources).

[0]
[https://i3wm.org/docs/userguide.html#hidpi](https://i3wm.org/docs/userguide.html#hidpi)

~~~
usr1106
"Xft.dpi: 192" in .Xresources is recommended everywhere. However, when the
desktop under Xbuntu starts it turns out that this setting has been ignored
(or overwritten later). Haven't found out why. Other settings in the same file
work as they should.

So this is the standard Xfce desktop, maybe I should try with i3. I use i3 at
work, but xfce at home. No exact reason why, maybe it's just good to know more
than one systen :)

------
diehunde
Congratulations! Works pretty good on my Linux machine.

------
kbumsik
Be cautious when binding Alt key by default.

In some terminal programs they report Alt key differently (use showkey -a) so
it may lead confusions.

------
msis
How is this different than [https://www.byobu.org/](https://www.byobu.org/) ?
You can run byobu with screen or tmux.

------
sys_64738
Does this work inside an Emacs shell?

