Occasionally, I have switched back to XTerm on my Linux systems and it’s always been fine. Good performance, good compatibility (everything runs correctly in XTerm), what else do you need?
- Tabs
- Clickable URLs
Otherwise, XTerm is solid. The source code is a bit of a nightmare.
I used to have a script that I bound to right-click instead of xdg-open. In addition to opening URLs, it also extracted the current directory from xterm's title so that I could open files with the mouse as well. I called it plumb (after the Plan 9 tool).
Unfortunately I lost the script and am not interested in rewriting it, but maybe it gives you some ideas. You could dispatch any action you want based on patterns in the selection.
I get tabs from my window manager (fluxbox), but not sure if that lacks some magical functionality you might get from it being built-in to the application. I rarely use it though, rather organizing things by whole virtual workspaces instead.
The funny(ironic) thing is. tabs as a desktop metaphor belong to the window manager.. however tabs, as implemented, were a revolt against window manager tabs.
If I understand history correctly, with the meteoric rise in popularity of our modern day terminal(the web browser) people were wanting to run more and more browsers at the same time. as the existing desktop manager state of the art(probably windows 95) was coming up short when dealing with the number of windows people wanted open the browser manufacture Netscape said fine, we will do it our self, this is where my memory gets fuzzy, I forget if it was an early firefox(phoenix anyone) the full mozilla browser or netscape proper(6 ish timeframe) that invented tabs, but they were and still are a very popular way control your many many browser windows you had open.
Really in the wrong layer however, it should be your desktop manager that provides tabs, not the application, and some do, but it is not a common thing what with the way DM tabs fight application tabs.
I remember when Phoenix got tabs, it was a killer feature for me because I was using some environment which didn't handle tabs itself (KDE and Windows). It was great not having to deal with a ridiculous amount of window buttons in the task bar.
But now, we've come full circle. I'm using i3 and adore its tabbed windows feature. However, it's basically impossible to disable tabs in current browsers. Firefox has some extensions [0], which combined with some custom css to hide the tab bar kinda sorta work if you're ok with a janky experience. For Chrome, I haven't found anything.
I am not sure that it was first, but Opera was the first browser that I remember having tabs. Outside of browsers, I think UltraEdit was the first application that I remember having tabs.
Most non-tui programs being run in terminals don't operate that way though, and tui stuff resizes just fine. ps, for example, only outputs text to fill the terminal size and truncates the overflow (which is why it's not safe to grep). Not reflowing makes a lot sense when compared to the complication and bugs reflowing would bring.
Tried with SCO OpenServer (old UNIX) and modern Fedora, with Konsole and XTerm. Neither 'ps' in either terminal truncates output to fit the terminal. What 'ps' on what OS did that?
Some Googling indicates that on Solaris, 'ps' would default to 80 characters wide before truncating, apparently ignoring the size of the terminal. However even that apparently did not apply when piping; it would output the full line in that case.
It really is until you settle on a larger terminal size by default (I use 100x25 or 100x50 usually, sometimes 132x25/50 for lots of output.) I still miss it though. Don't know why they never added it, for example it's got a whole Tektronix emulator built-in so bloat and extra work are no excuses.
Some people are happy with TMux but it introduces some compatibility problems (TMux itself contains a terminal emulator, and not everything works correctly in TMux), and half the point of tabs is being able to organize them how you please—if you want move a tab to a new window, you can do that.
I think you'll be pleasantly surprised if you look into what tmux is actually capable of. It's extremely customizable, featureful, and well-documented. All of the complaints you've raised in this thread can actually be solved with a bit of configuration.
> TMux itself contains a terminal emulator, and not everything works correctly in TMux
tmux doesn't merely contain a terminal emulator. Rather, it is a terminal emulator. All terminal emulators have slight differences in behavior and tmux is no exception. But since tmux is actively developed, I haven't personally encountered any deal breaking issues.
Colleague uses tmux. Every couple months one of his tmux sessions crashes, and he loses everything that ran in it. Meanwhile I can't remember screen ever crashing on me. Don't see why I should ever take that risk.
tmux never crashed on me this past decade either. So unless you're telling me that some computer science breakthrough has made screen crash-proof, I don't see why I should avoid tmux and lose many of the features I rely on.
It's just anecdotal evidence. Maybe it's because he's running arch and gets all the buggy beta versions, I don't know, but other than that, maybe that breakthrough is called "being mostly a finished product that has been around for way longer"?
Interesting! I usually have tmux in every terminal. I like that it keeps the session around even if I do something dumb like accidentally close my terminal.
It is cool that the ecosystem is flexible enough to fit our basically opposite preferences.
My terminal will stop me from closing the terminal if there’s a program running. I’ve also encountered a few problems with tmux from time to time—certain shortcuts stop working in weird, hard-to-diagnose ways, if a program is being run through tmux, or through some combination of ssh + tmux.
Depending on what terminal you use, this is likely to be related to the remote host missing the right termcap files and therefore there's no way for tmux to know how to do certain things.
One of the nice things about xterm is this basically never happens.
One of my systems has that confirmation dialogue enabled, it is pretty annoying IMO, I don’t want to have to reach for my mouse just to close a terminal. (I’ll disable it at some point, it is a system that I mostly just remote in to anyway, so it isn’t a daily annoyance).
There’s a shortcut in Vim that my tmux config gets in the way of. Ctrl-a, increment a number. This is a weird shortcut to me, though, actually I’m happy tmux over-writes it!
I have my terminal set up so the window won’t close without prompting.
I also like being able to copy-paste things out of terminals, and Tmux makes it a bit difficult. I know how to use the scrollback in Tmux but it’s just so much easier to use the scrollback in a GUI terminal editor.
I think what you’re describing is more habitual than the strengths and weaknesses of different solutions. Which is fine but the discussion needs to be framed that way.
People disagreeing with me but that fact that we’ve had a dozen people propose a dozen different ways to do the same thing, that alone should be evidence enough that what we are arguing over is personal preference rather than “x can’t do y”.
Having been a Linux (and unix before that) user for decades now, I’ve seen people argue over vi vs emacs, KDE vs GNOME, GTK vs Qt, GPL vs BSD and so on and so forth. They make all sorts of well reasoned arguments but it almost always just boils down to personal preference at the end of the day. Yet it’s amazing how many people think that their preferences are unequivocal facts.
- Tabs
- Clickable URLs
Otherwise, XTerm is solid. The source code is a bit of a nightmare.