Live data from Hacker News

What's a good Linux terminal emulator that doesn't try to reinvent TMUX?

news.ycombinator.com

51–57 of 57 posts

Re: What's a good Linux terminal emulator that doesn't try to reinvent TMUX?

#51

wezterm has lots of bells and whistles, but is fast and you can ignore the other features.

Yeah I used to use alacritty with the ligature patch, but swapped to wezterm as it supports ligatures natively. It's fast enough, maybe not as fast as alacrity or kitty. I just don't use the built in multiplexer or whatever. I think if you're running tmux, a lot of kitty/alacrity's performance is mooted anyway?

Yeah, tmux is not super fast. I really have liked wezterm, everything is just right for me. It does just enough of what tmux does that I use.

Re: What's a good Linux terminal emulator that doesn't try to reinvent TMUX?

#53
Surprising related fact: terminal multiplexers appear to be a relative neologism, multiple terminal emulators running on a graphical system likely predate them by years. I've been trying to dig my way into the history for funsies recently, below is hacked out of my notes that will eventually be a post or article or something.

Window by Edward Wang is in 4.3BSD in 1986, and it's the earliest member of the species I can find.

Screen was initially written by Oliver Laumann and Carsten Bormann at TU Berlin in 1987.

tmux didn't happen until 2007.

By contrast, blit terminals could run multiple terminal emulators in graphical windows around 1982 (commercial by 84; http://doc.cat-v.org/bell_labs/blit/ ). Likewise, some of the UNIX workstation vendors' early windowing systems like Sun Windowing System (SunOS 1.0, 1983) supported multiple terminal emulators. The earliest graphical multiple terminal emulator is probably Xerox PARC's Alto, which could run multi-window Chat (which was more or less a telnet superset) for talking to PARC's bespoke MAXC PDP-10 clone or other ARPA sites in 1979 or so.

The necessary condition for software terminal multiplexing (a robust pseudoterminal system) has been around for a very long time in places like the DEC 36-bit lineage: it was present in the PDP-6 Time Sharing Monitor announced in 1967 ( http://bitsavers.org/pdf/dec/pdp6/PDP-6_TimsharingBroch.pdf ), and continued to be present in most of the PDP-10 systems, importantly the TENEX line, and was later available in some of the smaller DEC systems like RSTS for the PDP-11. That was enough to detach and reattach jobs to terminals, but I can't find record of a screen-splitting tool. There were some patches from RAND and BBN to 6th edition UNIX by the late 70s ( https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/dmr/p... ), but there wasn't really wide-spread PTY support in UNIX until 1983 when 8th edition and 4.2 BSD sprung TENEX-like psuedoterminals, which kind of puts a lower bound on UNIX-like systems having such a thing.

It's possible EMACS was first, still in PDP-10 environments. ITS EMACS had some kind of hsplit support early on, possibly as early as April 1978 ( https://github.com/PDP-10/its/blob/master/doc/eak/emacs.lore ), and later some limited terminal-dependent vsplit support was developed for Multics EMACS between 84-88 by Honeywell Canada on behalf of the Canadian Department of National Defense for use in translation work ( http://bitsavers.trailing-edge.com/pdf/honeywell/multics/CH2... ). I can't find a record of when Comint mode or something like it came into being, which is necessary to use it as a terminal multiplexer.

There's a whole diversion about SRI NLS being able to do terminal multiplexing in demos on a SDS940 running the Berkeley Time Sharing System by the late 60s. They never split to multiple text terminals in any footage I've seen, and at least early on it seems the apparent screen multiplexing in eg. the mother of all demos in '68, was done with cameras pointed at CRTs and analog video muxes.

Re: What's a good Linux terminal emulator that doesn't try to reinvent TMUX?

#54

Earlier quoted context omitted.

OP mentioned good colour support, which alacritty does not have.

How do you mean? I always thought the colours seem fine, and googling this it says it has 24-bit colour support[0] which almost seems excessive for a terminal. Are there some limitations or problems I'm unaware of? [0] https://wiki.archlinux.org/title/Alacritty#Colors

https://github.com/alacritty/alacritty/issues/109

Maybe I'm a bit harsh, but you see a lot of programs require work arounds.

Re: What's a good Linux terminal emulator that doesn't try to reinvent TMUX?

#55
post #50
post #25

Earlier quoted context omitted.

Doesn't it feel sketchy to run a terminal that isn't even packaged by Debian? I run a few non-packaged things, but I don't want my terminal, or shell, or kernel to be "some code from a some person on github".

I don't see how that is a property of a software. If it isn't in the repos of a distro, it is a property of the distro. As you got systemd and non systemd distros, Debian is in this a distro w/o alacrity.

No, not being included in Debian reflects poorly on the software. It implies there's something "wrong" with it. Perhaps it's too new, or too arcane, or in some other fashion doesn't live up to the operating system's extremely high quality and security standards.

I don't think this would necessarily be true with other Linux based operating systems (perhaps RHEL), but certainly is true in this case.

Re: What's a good Linux terminal emulator that doesn't try to reinvent TMUX?

#56

xterm: https://invisible-island.net/xterm/

I used to use

xterm -fn r24 &

to get a larger font on some Unix and IIRC Linux systems a while ago. Good memories of doing a lot of fun command-line stuff, including Unix command usage, writing shell scripts a la the examples in The Unix Programming Environment book, and also writing many command-line utilities in C, and later, in Python ... :)

Post reply on HN