7 ms·
What's a good Linux terminal emulator that doesn't try to reinvent TMUX?
I don't need tabs, or sessions, or startup scripts or even mouse support. I just need a terminal with good colour support and fast performance, without any of the bells and whistles that are utterly wasted on TMUX users.
- pwg 4y agoUnsure what you consider as "good color support" but you might want to look at the original (xterm) or at rxvt.
- thesuperbigfrog 4y agoxterm: https://invisible-island.net/xterm/ https://invisible-island.net/xterm/
- vram22 4y agoI 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 ... :)
- michaelsbradley 4y agoI enjoy Kitty’s good color support and performance, though it does have a lot of bells and whistles in which you’re not interested: https://sw.kovidgoyal.net/kitty/ https://sw.kovidgoyal.net/kitty/
- qbasic_forever 4y agoAlacritty: https://github.com/alacritty/alacritty https://github.com/alacritty/alacritty
- dixie_land 4y agoI use Guake, mostly to bring up the "console" as a full screen overlay, like you would with Quake :)
- 29athrowaway 4y agoAs a former Guake user, I recommend you to try Tilix.
- neilv 4y ago`rxvt`. Debian has a few different packages, for different build-time options.
- mijoharas 4y agoAlacritty is simple and fast[0] (it does have mouse support, but no tabs, sessions, or startup scripts as far as I know. Configuration is all via config file.). Is that the kind of thing that you were looking for? [0] https://github.com/alacritty/alacritty https://github.com/alacritty/alacritty
- LAC-Tech 4y agoOP mentioned good colour support, which alacritty does not have.
- mijoharas 4y agoHow 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://wiki.archlinux.org/title/Alacritty#Colors
- LAC-Tech 4y agohttps://github.com/alacritty/alacritty/issues/109 https://github.com/alacritty/alacritty/issues/109 Maybe I'm a bit harsh, but you see a lot of programs require work arounds.
- blahgeek 4y agoRegarding terminal emulators, I believe that by "fast" people usually mean "low latency" instead of "high throughput". Apparently alacritty has a good performance on thoughtput according its benchmark with vtebench, but it does not provide good latency performance according to [0]. [0] https://danluu.com/term-latency/ https://danluu.com/term-latency/
- srcreigh 4y agoI agree, 34ms is unacceptable latency. Let's all use eshell in Emacs instead.
- nicative 4y agoextrateterm is pretty good (https://github.com/sedwards2009/extraterm https://github.com/sedwards2009/extraterm)
- bitexploder 4y agowezterm has lots of bells and whistles, but is fast and you can ignore the other features.
- bongobingo1 4y agoYeah 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?
- bitexploder 4y agoYeah, 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.
- deleted 4y ago[deleted]
- ilyt 4y ago...unbind "new tab" button ?
- NayamAmarshe 4y agoI love Konsole, it's super customizable and easy to use.
- 29athrowaway 4y agoKonsole is faster than Alacritty, but much easier to configure. uxterm is the fastest. Latency in milliseconds Program mean std min 90% max uxterm 1.7 0.3 0.7 2 2.4 mlterm 1.8 0.3 0.7 2.2 2.5 Konsole 13.4 1.2 11.5 15 16.1 Alacritty 15.1 1.2 12.8 15.9 26.3
- danielheath 4y agoThose Alacritty numbers look an awful lot like reporting framerate tuning rather than underlying performance (16.6ms latency being one frame at 60hz).
- loxias 4y agoUnsure how that was measured, but I'd like to see urxvtd up there. I'd bet a beer it's statistically significant faster. :)
- 2OEH8eoCRo0 4y agoWhat's wrong with the default in whatever distro you're using?
- mijoharas 4y agoNot all distros have a default (e.g. Arch)
- NateEag 4y agoIn some sense it's not a good terminal emulator (I hit several glitches in it on macOS, though it seems to do better on my NixOS machine), but I'm in love with cool-retro-term for its gorgeous CRT-style visuals. https://github.com/Swordfish90/cool-retro-term https://github.com/Swordfish90/cool-retro-term I mention it because it doesn't have tabs, saved sessions, or any of the other features tmux handles. So, it's not a bad fit for heavy tmux users.
- Eleison23 4y agoA terminal emulator is a high-value large attack surface that any hacker worth his salt would love to get into the supply chain. Therefore, unless your Unix machines are toys, it's a good idea to stick to reputable and well-maintained software, and for me that means what's in the distro's default repos. Every time you add third-party gunk you open yourself up to exploits from God knows where.
- justinludwig 4y agoIf you're using Wayland, foot is fast, lightweight, and has good color and font support: https://codeberg.org/dnkl/foot https://codeberg.org/dnkl/foot
- puppybang 4y agoHere's a list somebody posted yesterday on the arch reddit https://github.com/asdf8dfafjk/Terminal-Features/blob/main/Features.md https://github.com/asdf8dfafjk/Terminal-Features/blob/main/F...
- loxias 4y agoI use urxvtd and LOVE it. It's blissfully fast with a smaller memory footprint than anything else I've tried. edit: I should have mentioned, having the minimal overhead and most responsive terminal is a "tier 1" priority for me. Urxvtd is the fastest, and lightest weight terminal period. Either that, or something has changed since I spent a long time picking it.
- agent281 4y agoAnd the name just rolls off the tongue!
- wilsonnb3 4y agost https://st.suckless.org/ https://st.suckless.org/
- tmtvl 4y agoI used Zutty (https://tomscii.sig7.se/zutty/ https://tomscii.sig7.se/zutty/) for a bit, it's nice, but Konsole has nicer integration with the rest of KDE, so I went back to that.
- oneplane 4y agoMost distro-default/DE-default terminal emulators don't really make you do 'more' than just have a base terminal emulator. The extra stuff (in the likes of gnome-terminal for example) only surfaces when you actually use it, except for when you have duplicate key binds. If you don't use a DE, or don't like Qt/GTK based engines, urxvt and xterm are the best remaining options. Zutty is an option if you don't mind trying (often) unpackaged software, but then st would fit as well with the performance difference being that Zutty leverages GPU rendering for more performance and st doesn't seem to do that by itself. If graphics isn't your thing and you're just on the frame buffer directly, there is fbterm. A lot of the 'advertised' emulators seem to be targeting aesthetic and 'cool' marketability, some are even based on electron or try to put filters on the output...
- hestefisk 4y agoWhy not just use tmux? It’s super nice.
- christophilus 4y agoI use foot, which has been quite good.
- gtirloni 4y agotilix https://gnunn1.github.io/tilix-web/ https://gnunn1.github.io/tilix-web/ You can disable everything in it. I just use it mainly for the panes.
- miloignis 4y agoFoot's already been mentioned, which is my Wayland goto. For X, I like Sakura.
- anoother 4y agoevilvte sakura
- friend_and_foe 4y agofoot works great for me.
- 1vuio0pswjnm7 4y agoWhy colour support. As a tmux user, I never use it. It's utterly wasted. But seriously, here is one option. Tmux is a BSD project. On NetBSD, it replaced window(1), which was quite basic and did not have GNU screen or tmux bells and whistles. Thus, to avoid such features, one could use window: https://ftp.netbsd.org/pub/pkgsrc/distfiles/window-20120215.tar.gz https://ftp.netbsd.org/pub/pkgsrc/distfiles/window-20120215.... Linux users can use pkgsrc to compile it. The expression "doesn't try to reinvent" may suggest that the desired alternative needs to have been written after tmux, not before. If so, then window will not qualify. It dates back to the 1990s, at least. Footnote - I admire the minimalism sought here. I consider myself somewhat of a minimalist and the size of tmux has never bothered me. Looking at the source, it is relatively easy to remove features. I have not used a mouse on computers I own for over 20 years. There are many tmux features I do not use. Still, I have not felt the urge to remove them. I use a statically-linked tmux with a few customisations that weighs in at 1.2M. That is smaller than the statically-linked text-only browser I use which comes in at 1.3M. But perhaps I will try to trim down tmux as an experiment if these unused features are in fact taking up significant space.
- slim 4y agomlterm. it has no bells and whistles a part from full unicode support including bidi
- vermaden 4y agoI use these (depending on the needs): - xterm - urxvt - sakura - terminator
- ElectronBadger 4y agoBeen using urxvt for many years, this year I replaced it with kitty (https://sw.kovidgoyal.net/kitty/ https://sw.kovidgoyal.net/kitty/), will stay probably for as many years as urxvt :)
- PAPPPmAc 4y agoSurprising 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/ 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 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/pty.c 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 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/CH27-00F_emacs_Nov86.pdf 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.