mtm is a pet project of mine that a few people seem to like: a minimalistic take on terminal multiplexing. I’ve finally gotten it pretty much exactly where I want it to be, and thus I have deemed 1.0 complete:
Oh, I actually wanted something like this some time back! I was working on an embedded arm thing running Linux using a serial connection, and wanted a multiplexer, but even after spending too long getting tmux compiled for it, it refused to run because it didn’t like how the locale was configured (and that wasn’t something I could just easily change, because all changes to the file system happened in an overlays-type thing out of ram, so changes weren’t persistent).
I just gave up, but had I known about mtm I would’ve given that a shot.
How does it fare with vttest or esctest?
Pretty good. There was an earlier branch (called “full-featured”) that passed basically every vttest test that could be reasonably passed (including accurate VT52 emulation), with the exception of BCE-style colors (which aren’t standardized). Some of those features were stripped out because they unnecessarily complicated the code.
Now it passes every test for VT100/102-level stuff plus some extra ISO 6429 cursor motion things and character repetition. Basically, the goal was to emulate the terminal described by GNU Screen, which mtm does…better than Screen itself, in some cases.
There are some things that mtm will never be able to do (like resize the terminal to respect DECCOLM mode, for example), of course.
(And now that you ask, I notice that sometime between now and a couple of months ago, mtm is failing the screen accordion test….dang it. Looks like there’s gonna be a 1.0.1…)
Looks like an awesome idea. I love the concept of having a really small terminal multiplexer. It is unfortunate that it fails to pass through sixel though. I would love to see more wide support for sixel.
I had never heard about this before and I just tried it (using fish as my interactive shell). It appears super, super slow: When I run “ps faux” in an mtm window/panel the output is chunked. Without mtm it is rendred almost instantly. And with mtm a text editor like jed seems to take ages to initialize its display.
Am I doing something wrong?
Ditto. Scrolling in vi is painfully slow.
What OS/terminal emulator/character encoding are you (and @eeks) using? On Linux with xterm, there’s no detectable difference with mtm running and without, at least for me…I tested with a VTE-based emulator too; again, no difference.
Feel free to open an issue on GitHub.
I am using the terminal emulator sakura (“A terminal emulator based on GTK and VTE”) with $TERM=xterm-256color on ArchLinux. The same thing happens with the lilyterm emulator, and actually also in xterm.
Charset is UTF-8 ($LANG=en_DK.UTF-8).
If I run “ps faux” right now the output is 26600 bytes and I see 6 “chunks” in mtm, so could it be something with a buffersize of 4096?
It’s neat to see more small software under the GPLv3, a good license. It’s easily audited and not liable to be locked away. That it’s rather finished is also good; more software should strive to be finished.
Nice! I sometimes run just a multiplexer (dvtm) on the framebuffer to maximize my laptop’s battery life when I’m just programming. Optimizing for battery in this mode has gotten absolutely silly (read “fun”), so next weekend I’ll install mtm and see how much power it uses in comparison to dvtm and tmux. I feel like my workflow might miss windows and pane resizing, but maybe those aren’t as crucial as I think.
Cool project! It’d be cool to see a terminal multiplexer that doesn’t require ncursesw/a Unicode locale. It’d be nice to have some terminal multiplexer on my IRIX machines, but IRIX doesn’t have any Unicode locales. I’ve had no luck finding any multiplexers that don’t require Unicode in some fashion so far.
Anyways, super sweet project!
mtm doesn’t require Unicode, just wide characters – and it doesn’t care if sizeof(char) == sizeof(wchar_t). It does require ncursesw, but only because of the aforementioned wide-character-ness. I’ve tested it with ISO-8859 and it seems to work just fine (though, caveat emptor, I haven’t tested that configuration much).
sizeof(char) == sizeof(wchar_t)