XTerm: It's Better Than You Thought | Hacker News Reader

XTerm: It's Better Than You Thought

aduros.com

154 pointszdw152 comments

All these Xorg/X11 problems people complain about... I honestly don't see them.

I've been using Xorg in one form or another since 2005-2006 and frankly since we all got automatic configuration and said godbye to Xorg.conf it's been a very very pleasant experience.

I've been using both nVidia and intel cards, 1/2/3 monitors (in various arrangement) and network stuff (ssh -X and similar), and a videogame from time to time.

Even xterm, with the right fonts, it's a very nice setup. I almost can't see the difference between a gtk emacs window and an emacs session running in xterm-unicode with proper fonts and antialiasing.

Xorg might not be "optimal", but it works very well for me and I won't be switching to anything else until a wayland or whatever reach feature parity (including but not limited to network transparency).

Whatever,

> All these Xorg/X11 problems people complain about... I honestly don't see them.

That's because DonHopkins is shitposting quotes from the Unix Haters Handbook, which came out in 1994 and contains gripes about Unix dating back to the 80s.

The Unix ecosystem, including X11, evolved a teensy tiny bit since then.

One wouldn't notice that, given how many eschew the progress made and live in the command line as if stuck in the 80's.

It's not as much "the command line", but being able to talk to your computer using a human-like language, instead of pointing with your finger like a baby or a monkey.

Do you know any computer/user interface that is based on writing what you want to do? (instead of selecting it from a small list of possibilities) The only one that I know is the "primitive" command line.

Yes, the REPL as used at Xerox PARC, while Bell Labs was busy with troff.

Don't you have a modern example? I thought you were despising 80s technology.

UNIX is still busy trying to catch up with 70's world from Parc Place, and apparently the 80's UNIX world is what UNIX aficionados want to stay on.

No need for more modern examples.

But what is there for power users today? AFAIK Unix is the only viable option from a very pragmatic point of view. So it's not about being aficionados, it's about being pragmatic.

The millions of users using IDEs, Jupiter notebooks and tablets disagree.

Most of them have no effective way of automating their work.

Every piece of software (Excel? Word? Outlook? Autocad? Photoshop?) has its own system of automation if it has one at all, with many of the skills complicated to learn on one hand, and not transferable on the other. On tablets, automation is essentially nonexistent.

Whereas on Unix, there's a mostly-unified system of automation (shell), with mostly transferable knowledge.

If there is nothing in your work that benefits from automation, you wouldn't care. But you'd also be rather special, IME - most people spend a lot of time on recurring and automatable actions they gain no benefit from repeating manually.

IDEs for scripting languages with graphical REPL.

> graphical REPL

Those are useful and beautiful, but they are particular cases of "command lines", aren't they? A bit limited, in that they are only useful for developing on that IDE, and not as a general interface for your computer, but useful command lines nonetheless. I thought you were opposed to command lines.

I am not an expert of *NIX OS, but in my two years of learning the philosophy of the OS I noticed that almost every implementation of a GUI concept or idea has it origin from CLI, the GUI is just a manner of automating things in a way that once you know what to write to the computer to do what you want to achieve, that task remains in the form of that button, but again in my opinion a button is just another abstraction of an "alias" in the CLI for a command or just a text file whit a script, it is useful for some cases to have buttons, for example editing a video in CLI is not a optimal choice for that task, I mean you can but probably will take you much more time, specially if you don't know the tool, but in the other hand, almost every video editing GUI app uses "ffmpeg" ( a CLI app and library) as it backed, so probably learning ffmpeg will teach you how to use almost every app of video editing out there. Text editing in my opinion is so slow in a GUI except for some programs like emacs, gvim and others (but whit proper extensions), and with a bit of knowledge you can achieve the same or maybe if you are persistent and develop the love for the CLI a more powerful "button" for your development environment that fits exactly your needs, and it immediately gives you more freedom, you never will to wait until the next version of your spyder or what ever IDE out there to make something you want to do, and if it fails you know how to fix it because you wrote it, that said, REPL came from "SLIME" that means "Superior Lisp Interaction Mode for Emacs", ergo, emacs users have been using REPL long time ago before, even before spyder or any "modern" IDE we actually have, that said, there is a plugin for vim too called vim-slime inspired by SLIME, where you can send words, lines, block or whole text files from your editor to other app, lets say tmux, your browser or any others, so vim, vim-slime plugin, tmux and a script to send text from your editor to shell executing python or ipython3 console or python-qtconsole gives you the REPL feature that is so acclaimed these days, and I want to say that since I implemented it for python development until now, it never crashed, so really I do not miss nothing from any IDE out there jeje, I hope some one who read this out there, expanded his main a bit and break some limitations with these little tip!. I'm currently changing mi mind for a better life in the shell, so any useful resource you want share with me or correction to me, will be received gracefully.

Siri and alexa? You tell it what to do in pretty darned close to human language

Good answer! (but I prefer typing language with a keyboard, instead of saying it out loud, as I'm not a native English speaker and it feels very unnatural to me).

Yet, is it possible to use siri or alexa for all your computing needs? Can you copy files around, convert a few images from tiff to jpg, download, compile and set up a nginx web server, hack a bit the code of the server and recompile, etc.? Because I can do all of that from the comfort of my "obsolete" command line.

I would love the option of being able to tell my computer to do things like this some day.

But you already have this option, it's called "xterm + bash"

By speaking, not typing.

I use my terminal and shell all day. :P

Human-Computer Interfaces have different needs from Human-Human interaction, in particular they need to be unambiguous (which the natural language isn't), very precise and concise. For these reasons Siri and Alexa would be terrible to perform tasks which would be very quick in a shell. Also Siri and Alexa are not local and not privacy respecting.

They are very imprecise, and they cannot fit on your desk. The device is just a speaker, but the actual computer is in a data center elsewhere.

This is a great example, but is still horribly limited in functionality. I use my Google home constantly, but I've built a mental model of its limitations and am still frustrated by the "latency" involved when my model assumes it can do something it can't.

Hopefully we're getting there though!

X11 is a keylogger, for one. Network transparency is a vulnerability, not a feature.

Yes, and Wayland is a pile of shit, so what's your point? Xorg has this one problem, Wayland has countless problems.

Xorg is stable and proven for decades; Wayland has been incomplete and buggy for decades.

I don't run Wayland, PulseAudio, DBUS, or SystemDumpsterFire on my system, and don't miss any of them.

I don't run strange binary code on my system either, so keyloggers aren't really a concern.

I find it ironic that people who routinely shovel foreign binary code onto their system (even automatically downloading and installing it, no less) from untrusted and untrustworthy third parties, are so all-fired concerned about these trifling imagined Xorg security problems.

Oh shut up.

> Be kind. Don't be snarky. (...) Please don't sneer, including at the rest of the community.

- https://news.ycombinator.com/newsguidelines.html

Please, let's not reduce the level of discussion over here. Let's keep this respectful.

I have deliberately chosen to keep my answer to the OP on point, even though I disagree just as strongly.

Please don't do this. We ban accounts that post like this, and have had to ask you not to before.

I'm not going to ban you because you've mostly been posting good comments lately, which is cool. But comments like this do more damage than good comments add value, so please don't do that anymore.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html, we'd be grateful.

Network transparency is definitely a feature. I can't count the number of times when X forwarding was an extremely convenient feature to have.

Back in the 90's, some machines shipped with X authentication disabled, open to the world (SGI IRIX 5.x was one of these.) Back then, few people used firewalls. X11 keyboard sniffing was very common in some circles.

My absolutely essential XTerm settings:

  ! Convert Meta-x into "ESC x", not "ø"
  XTerm.VT100.metaSendsEscape: true
  
  ! Allow HT (TAB) in paste; i.e. do not convert to space character
  XTerm*VT100.DisallowedPasteControls: BS,DEL,ESC
  
  ! Assume window titles are UTF-8 encoded
  XTerm.VT100.utf8Title: true

(Add to your ~/.Xresources and/or ~/.Xdefaults file.)

I use xterm because I'm too lazy to switch, I guess. It was never bad enough for me to switch and it's present virtually everywhere, so I don't need to bother installing my favorite niche term (kind of like sticking with bash when zsh was indisputably more awesome).

To the best of my knowledge, one downside is the text rendering is synchronous. Read a character off the tty, try to display it on the screen. It's fine until you go and cat /dev/mem or something like that. Many GNOME-ish terminals use vte which drops frames if it can't keep up rendering.

I also run into problems with bad display managers or DEs that don't load ~/.Xresources or ~/.Xdefaults (looking at you Debian gdm).

> To the best of my knowledge, one downside is the text rendering is synchronous.

I find this to be a feature, it's part of what makes xterm a terminal emulator.

There's a speedhack in recent xterm that makes it behave more like libvte, but I forgot the incantation to enable it.

> Many GNOME-ish terminals use vte which drops frames if it can't keep up rendering.

Cannot you that with Xterm too?

XTerm*fastScroll: true

I use xterm because it's one of the only terminal emulators that allows me to disable the alt-screen (titeInhibit). Apparently I'm one of the few, but when I vi/view a file and exit, or read a man page and go back to the command line, I still want to be able to reference what I was just looking at.

Absolutely! I often use cat in tmux instead of less because of this. Will try xterm now, too.

You can use the -X option to less to avoid it clearing the screen. To set this option by default, put "export LESS=-X" on your profile.

If you want the same sane behavior for vim, add "set t_ti= t_te=" to your .vimrc.

Indeed, but it's more painful to get these things set across all the systems and accounts I use, even given Ansible. Doable, but titeInhibit is kind of nice. :-)

With Kitty, which I've been playing with and doesn't support titeInhibit, it requires deploying a termcap package everywhere, which is also painful, but I ended up building a version with those escape codes removed, which was kind of a benefit of having to use and deploy a custom termcap.

In addition to the sibling comment, tmux has the per-pane option 'alternate-screen'. You can set its default with 'set-option -g alternate-screen off'

Yeah, I'd say xterm is pretty freakin' awesome.

While Hackernews was busy grooming their Alacritty setup and holding drag races between it, iTerm, and whatever bloated terminal Microsoft came up with to see which could cat a huge file the fastest, I've been just using xterm. xterm -- it's the standard terminal emulator.

xterm:

* actually emulates a terminal and passes a set of compliance tests to determine how VT-compatible a terminal is (other TEs emulate xterm, poorly)

* is still compatible with bitmap fonts

* has a reputation for being slower than other TEs, but that's only because by default it doesn't cheat and commits every screen update. Other TEs, in order to increase their chances of winning the drag race, will skip updates they think you won't see. This can be enabled via a command-line option or X resource in xterm, but makes xterm less compatible.

* comes with every Linux or BSD distro and works fast on nearly any graphics adapter

What is the practical value in better VT compatibility?

I'm not familiar with the history, but I guess this is essentially referring to a standard defined by hardware products from the 1970s? Why is that still relevant?

Same as adhering to any standard? The software you want to run produces VT-compatible output, the terminal consumes that and provides a display.

What i mean is, many other computer standards become obsolete and get replaced. What is so special about this standard from the 1970s that has given it so much staying power?

It is a software standard, influenced by hardware, which has outlasted nearly every other hardware and software standard of its time. Doesn't that strike anyone else as bizarre?

The VT standard is roughly to the application layer what RS232 is to the physical layer: open, easy to implement, and damn near ubiquitous. It makes a nice Schelling point for when you want to throw up a rudimentary UI.

Example: I once worked for a robotics firm that built its own custom batteries. The battery engineers wanted an easy way to monitor battery health and status. So they added code to the firmware to make the tiny microcontroller that monitored and controlled the battery to periodically spit out screenfuls of health information in VT standard. Then, all they had to do was attach a laptop to the battery over serial and start up Windows HyperTerminal, and they had a full (text mode) status display.

This could not be done so easily without a terminal standard that's nearly universally recognized.

That's a really interesting example. I think I'm having a hard time articulating my question, partly because I don't fully understand the entire stack of software and standards underlying a modern terminal app on a desktop. I feel like there is a lot of historical baggage in that stack, but I don't know where exactly, or why. I was using "the VT standard" as a sort of proxy for that historical baggage, but maybe that's not accurate.

Alongside fvwm (the original one), I imagine.

I use a mixed environment. My servers are FreeBSD, OpenBSD, and about 5 different linux distros.

I can only get consistent screen output if I use Xterm. rxvt, Alcrtty (sp?), Konsole, Gnome Terminal and all others that I have tried mungle ncurses, and/or other screen decorations (like using ASCII +------+, or TAB/Space, "decorations").

Even if I do get rxvt dialed in from one client, if I connect from a different workstation with a different client it's all a mess again.

I know xterm is the slowest of the bunch, but it always works with minimal putzing.

Most "modern" terminals are surprisingly buggy (for lack of a better word), that is, they do not conform to the VT100-series specs (and less documented, but well known quirks). Here's a look at some of them: https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-...

> I know xterm is the slowest of the bunch, but it always works with minimal putzing.

I though that Xterm was the fastest in terms of latency and configured adequately, pretty going dealing with big amounts of text:

https://anarc.at/blog/2018-05-04-terminal-emulators-2/

Xterm*fastScroll: true

I am really grateful for Xterm, it is a great default for all my machines.

The only way I've found to get consistency is use GNU screen as a translator.

> ...it turns out xterm has incredibly low input latency compared to modern terminals.

This boggles my mind. What on earth does a windowed terminal need to do that should result in any latency on a modern machine?

We had full ANSI-addressible displays that ran faster than the eye could read over serial lines in the 1980s. What on earth additional does a terminal program do and why would I want that?

Well, it first needs to take the your input and pass it through the HID subsystem into userspace to the appliction, which then responds to it and sends it to the terminal, wjocj collects the output and then emulates whatever control codes there are, then updates its internal model of whatever PTY thing it is emulating, then sends that to the screen and wait for the window server to pick up on those changes and then double buffer it onto the screen…it's complicated, to say the least.

But my point is that an Ann Arbor Ambassador terminal (with logic, not even an 8-bit processor) talking to a VAX 750 (about 1/2 MIPS, also passing data from kernel into user space) was lightning fast.

The internal processor that does nothing but scan my laptop's keyboard to send events to the "computer" is more powerful than the setup we used to have. Yet the entire thing is slower.

My Mac doesn't draw any faster than the Alto I used in the 70s.

> My Mac doesn't draw any faster than the Alto I used in the 70s.

Yes it absolutely does, you just don't notice because of the increase in fidelity. What was then 640x480 pixels is now a 4K display. The total number of pixels is several orders of magnitude more, the number of colors is now 16.7 million rather than 256, and the complexity of the scene has increased where we now have anti-aliased text and alpha blending.

Nit, but 640×480 -> 4k is single order of magnitude difference (307,200 -> 8,294,400).

Well the Alto was 6060 x 808 B&W bitmap display, but the machine was maybe .25 MIPS. The UI was pretty snappy -- faster than an IBM PC display.

Yours is the first comment to actually address my question.

Also, in the 70s, you have a bitmap font of max 256 characters of equal size. Nowadays displaying text requires font selection, text shaping (incl. kerning), glyph selection, text layouting (incl. line wrapping), glyph pre-rendering, and a final assembly step to get the composite image of all glyphs.

Want to skip font selection? No emojis for you.

Want to skip glyph selection? No ligatures or Arabic or Devanagari text for you.

Want to skip text layouting? No Right-to-Left support for you.

There is a whole crapton of legitimate complexity in the font rendering stack because we don't want to have the constraints of the 70s anymore (only 256 glyphs, fixed font size, monospace font only).

(Sidenote: For those of you who think "I'm fine with monospace fonts in my terminal", I am using a monospace font as well. But "monospace font" only means that all ASCII glyphs are equal-sized, which is a tiny minority of all glyphs a Unicode font supports. I have grown a very strong opinion regarding this topic since I started to learn Japanese and hence want to be able to deal with CJK characters.)

Most terminal usage will be restricted to the English-language software and source code, for expediency reasons or because English is the lingua franca of tech. You can usually get away without RtL and ligature/wide glyph support.

What I would like to see is a terminal that has a default high-performance monospace-only rendering engine, but gracefully and dynamically switches to a different rendering engine that supports the full-blown text layout capability once the terminal detects some input that makes use of these features.

You might be surprised how often you trigger that second code path. For just one example, an increasing number of CLI programs use emoji in their output, whether you like it or not.

I'm actually a great fan of using emoji to spice up terminal output. Most of these would be fixed width too, isn't it? I know there are wide emoji, but most times I see them around one char wide.

Emoji are square, which makes them overwide under most (all?) monospace fonts.

Yet nearly every serial terminal from that era tends to struggle to handle text at >9600bps without some form of flow control at some point.

I'd love to see text spew into my Terminal emulator at 960 cps these days!

https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

The Nongraphical GUI

XCalc After Several Resizings

https://miro.medium.com/max/434/0*LIDAYbj5NRANRGl7.gif

X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?

Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to purchase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn’t get all of those ugly fonts. It’s a trade-off.

Here’s a non-Medium version[1], since Medium is similarly but completely unrelatedly, a disaster.

[1]http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...

The original UNIXUX site is very clever, but if the guy who actually wrote it is linking to Medium instead, I’m not sure if we can overrule him.

No one is getting overruled, you now have one additional choice of links to click on for the same material, free of charge.

Sadly the unixsux site lost its luster when Netscape disabled the <BLINK>_</BLINK> cursor.

http://www.art.net/~hopkins/Don/unix-haters/login.html

Here's my not-so-subtle Solaris joke about how AT&T was ruining Unix:

http://www.art.net/~hopkins/Don/unix-haters/panic.html

I mean clearly the blink tag had to go. It was annoying, unsafe, a blight on the web; not at all like CSS3, JavaScript, WebAssembly and whatever that DRM thing was called, encrypted media extensions, was it? Priorities, man!

Thanks for coming out, the X Windows Chapter was my favorite in the book. :)

Shameless plug: You could buy a copy of the book! ;)

https://www.amazon.com/UNIX-Haters-Handbook-UNIX-Haters-line...

Or just download the pdf file:

https://web.mit.edu/~simsong/www/ugh.pdf

Don, did you ever figure out the difference between a "client" and a "server"?

Sure: xterm a client of your display and keyboard and mouse, remote input and output services that the X11 server provides over the network.

And at the same time, a web browser is the client of computing and data servers in the cloud, provided over the network.

In reality, there can be many different client/server relationships existing in different directions over the same full duplex network connection. It's really a bi-directional multiplexed messaging channel, not a pure strict hierarchical relationship, and many client/server dependencies can go both ways over the same connection, at the same time. You can even run an ssh that opens tunnels in both directions, then tunnel X and http connections over that.

Once a connection is established, it really don't matter which end initiated the connection (or how many links and proxies and tunnels there are along the way) -- you're just sending messages both ways.

"Client/Server" is an over-simplified way of describing what's possible.

Only the server, actually serves the graphics to the user.

Within the context of the X Window System, the server is the body of code responsible for delivering the display to the user viewing it.

> Only the server, actually serves the graphics to the user.

The server actually serves the user to the remote client.

It's like "you are not the customer, you are the product". The remote program needs to communicate graphically with you, and connects to the X server to do this; therefore, you are not the requester of a resource, you are the resource being served. :)

Great analogy. Think of it like Amazon Mechanical Turk.

I like it. Clever, and current context relevant.

Cheers.

Think of it in terms of a print server. It's a long-running process that other processes connect to, in order to request a service. It handles the "impedance mismatch" between the clients and the hardware it controls---in the case of a print server, it demultiplexes requests and translates them into something the printer can deal with; in the case of X, it displays the information as requested by the client and provides notifications of events as requested by the client.

I always ran xdaliclock

Xterm has popup menus, though I don't know when they were added. I've blown people's minds when they saw them. There's also the Tektronix vector terminal emulation in a separate window. It's also trivial to modernize it with features like scroll wheel support because of the flexibility of X resources.

I've found the latency of Konsole to be phenomenally low. I can definitely tell the difference between Konsole and GTK-based terminals, but I can't really tell the difference between the latency of Konsole and XTerm.

never understood whar extra features people need out of a terminal that they are building new ones. heck there are electron based terminals

I use window separation and profiles in Konsole every single day and alarms are handy when needed.

I have a 4K display and terminal has it's own virtual desktop, separating a Konsole window into nested tabs is a must to simplify the navigation between tabs since you can switch to other groups by a single hotkey.

I use profiles to visually differentiate tabs for different purposes (e.g. ssh to hosts with master and replicas of DBMS, which I did years prior to [0] happened), some made for fixing production hosts so they have an infinite logging enabled, and one can alter hotkey schemes with those.

Alarms are just an easy way of triggering a notification when a task is done or failed, saves time and brain resources.

You can get a fair bit of that with terminal multiplexers like tmux. It does not have the ability to style different tabs. But it has advantages too. For example, you can have multiple terms connected to a single tmux session, you can run tmux when ssh’d to a remote server, the tool is not tied to a particular vt.

Not to say your setup is deficient, but I think I understand where the parent is coming from.

Am I the only person who likes "prehistoric x-apps"? E.g. xdiskusage is far better than any other disk usage app I've tried.

Proud xeyes user here.

Have you tried duc for disk usage? It's minimal and has a nice visualizer.

I did ... but tbh can't remember what my beef was with it now, I just remember that when I compared them all it wasn't a favourite, hahah ...

I settled on xdiskusage and gt5 (the latter when I'm on a terminal). Both great tools.

For people interested in playing around with different terminal emulators, you’d do yourself a service trying kitty [https://github.com/kovidgoyal/kitty].

It made my experience on high DPI screens far better. You can find it packaged up in the usual places (e.g. Debian).

I've recently taken up alacritty (+ tmux), which is fast; nice, and scales on displays sensibly.

I'd been using urxvt w/ a plugin for tabs for eons previously. I'be been mutating my tmux config to match the urxvt + screen binding I've been used to.

I switched to kitty because it supports a killer feature I became accustomed to in iTerm- a keybind for "Open a new terminal in the same directory as the current terminal."

alacritty offers that as well.

This is something that I never learnt how to do with Xterm, I put the keybinding in Bash:

bind -x '"\C-T": _terminal_here'

I would love to know how to execute a command from Xterm directly, I am sure that it is possible.

Try this:

    XTerm.vt100.translations: #override \n\
        Ctrl <Key>T: spawn-new-terminal()

That opens the new terminal in the home directory, right? My keybind opens it in whatever directory I’m already in which I find handy in deeply nested projects.

It opens in the current directory, not just home.

Sweet!

Works like a charm, thank you.

> Offloads rendering to the GPU

I don't understand this - isn't all rendering on a typical macOS or Linux desktop done via the GPU?

I believe the software has to take advantage of the GPU. The `foot` terminal renders on the CPU instead of the GPU, but beats GPU-accelerated `alacritty` anyway due to other effiency hacks described on their Performance page:

https://codeberg.org/dnkl/foot/wiki/Performance

Hmm I think it's more the case that an application has to go out of its way to not render on the GPU. High level frameworks' basic rendering operations are, of course, always GPU accelerated. They'd be crazy not to be! It looks like Foot is rendering using CPU by talking directly to the compositor.

There are various ways to take advantage of the GPU -- the so-called GPU-accelerated terminals contain bespoke OpenGL programs ("shaders") to do rendering on the GPU. Here's an interesting way of doing it: https://tomscii.sig7.se/2020/11/How-Zutty-works

Specifically, kitty uses VRAM as a font rendering cache: https://sw.kovidgoyal.net/kitty/performance.html

Right... but doesn't every serious desktop GUI framework already do that? They aren't drawing every glyph every time from the original curves, and where else would they store video data than... the video RAM.

Here's a few other useful binds related to zooming out, in and resetting zoom:

    Ctrl <Key> minus: smaller-vt-font() \n\
    Ctrl <Key> plus: larger-vt-font() \n\
    Ctrl <Key> 0: set-vt-font(d) \n\

And 2 other config options to help reduce trailing spaces when selecting text:

    xterm*highlightSelection: true
    xterm*trimSelection: true

Thanks for those trim settings, useful!

I'll swap you for these. I don't want any automatic opening of URLs, but I do want to make it easier to copy-paste them:

  xterm*on3Clicks: regex [^ ''""()<>$+]*
  xterm*on4Clicks: line
  xterm*on5Clicks: group

Very handy, thanks!

Further tips that might interest people:

Xterm should support sixels out of the box but needs further configuration to make it work properly:

    XTerm*decTerminalID: 340
    XTerm*numColorRegisters: 256

If you want to scroll the content in alternate screens like less instead of the scrollback buffer with your scroll-wheel you have to enable:

    XTerm*alternateScroll: true

If you want a subtle and less jarring visual terminal bell you can enable this option which flashes only the current line and not the whole screen:

    XTerm*visualBell: true
    XTerm*visualBellLine: true
    XTerm*visualBellDelay: 20

OMG UTF8! Next I suppose someone will show me how to disable those !@#%ing colour control codes that always make my text blink? I don't want colour. I don't want syntax highlighting. I just want my old-school terminal. Mind you I'll probably have to sacrifice my cherished 8x15bold font (still installable after all these years) if I really want to go UTF8.

I do!

I use the terminal everything and even my IDE.

Give me all the fancy features and dream up more.

Just actually support vt100 when it is needed and in sometimes worse situations.

Our “serial” console solution is even worse then the old school days. God help us if we need to use it for more then the occasional evaluation.

You might be interested in https://no-color.org/ I implemented it for my mail client (listed on the website)

I set TERM=vt102 to get rid of the garish colors. You still get the basic colors, which can be useful sometimes.

You might like the showBlinkAsBold Xresources setting https://www.freebsd.org/cgi/man.cgi?query=xterm&apropos=0&se...

If you want no colors with xterm?

    xterm -cm

Most terminal emulators won't support the -S option. That is needed so that another program can feed data into an xterm that has been created as a child process.

I've seen it used for a modem dial-up program and I've seen it used for the emulation of old computers with serial consoles. It would probably find use with debuggers. Sometimes you just want to pop open a new window, and xterm is the only terminal emulator that will cooperate.

The option parsing is buggy. Only file descriptor 0 works, but that is good enough because of the dup2 system call. Fork, set up the file descriptors, and then exec an xterm like so: xterm -S/0 -T foo -n foo -name foo

I'd love to get the feature, with the exact same syntax, into all the terminal emulators. That would mean that x-terminal-emulator, which is a link to whatever the user installed, would always have the feature.

You can get a tabbed xterm this way (From stack exchange):

Do sudo "apt-get install suckless-tools", then run this command to have a tabbed xterm:

    tabbed -c xterm -into &

Press Ctrl+Shift+Enter to open a new tab and Ctrl+Q to close a tab. You'll find more info in the man page for tabbed.

It's decent and supports direct-color and all the obscure features of xterm of course, that others don't like querying and setting the color palette.

It doesn't support most(any?) of the bleeding-edge sequences for hyperlinks and underline styling.

It may have better input latency than xfce, but what are you running it on, a 486? Maybe for RPi, but—it has poor paint performance as well. It will flash if you try to do animation or scroll a complex screen. Bit of a toss up on the that front.

Anyway I find it useful for testing terminal sequences, but it's a tough sell as a daily driver. Things like tabs and a proper scrollbar are a minimum for me.

> Things like tabs and a proper scrollbar are a minimum for me.

I use xterm in tmux, no need for native scrollbar or tabs.

Do you mean the reverse? I'm using a number of applications, the terminal is but one. So, I find a consistent interface is desirable.

I like composability, to stack software together, like chaining coreutils in bash. Vim inside of Tmux inside of Xterm inside of Xorg on Linux. Every software adds its functionality to the stack, but no more.

What do you mean by scrollbar? Xterm has a scrollbar, and you can customize it with plenty of options.

Tabs I agree that it may be a showstopper for some, however in X you can use suckless tabbed to add support:

https://tools.suckless.org/tabbed/

For some of us, we just want the fastest terminal out there (in latency and startup), because everything else will be taken care by the window manager or Tmux.

I started using st from suckless and realized that met most of my needs, especially when I learned to use tmux properly. In some ways XTerm is the luxury version compared to st. I don't necessarily recommend st, but it is always interesting to learn that you can get by with a lot less than you thought you could. And it helps you learn some tricks you might not otherwise think you needed.

I use st as well. Honestly, the main reason is that I can configure it to use ligatures, whereas the few that offer ligature support aren't terminals that I prefer, and the terminals I like better don't offer ligature support. So, st it is. Otherwise, it's not the best with regard to overall capabilities (though that is because of my limited ability to write my own original patches for it, I suppose), but it's not the worst either.

I don't especially recommend it either, but I like it a lot for my own use. People who don't know how to patch C on Linux are probably not really going to want to use it with the default config.

I use sakura, since it has great support for unicode (presumably through libvte, which also xfce4-terminal uses). See e.g. https://i.imgur.com/G6arkK9.png using some extracts from http://www.madore.org/~david/misc/unitest/

- xterm just gives up (tried uxterm as well as the .Xresources settings here)

- st prints the arabic backwards (left to right, which I suppose you might prefer if you don't actually plan on reading it), has no colour on the emoji (which again you might prefer!), and completely fails to display the double-composed diacritics (this is a bad one, even if you prefer to KISS)

- I don't know what kitty is doing with the arabic, all I see are some strange rendering artifacts

- sakura (and xfce4-terminal) passes all the tests

Many years ago, I was surprised to find out that XTerm can also emulate a vector-based tektronix terminal.

The only application for it that I found was a previewer for TeX's dvi files that could render on the Tektronix terminal by drawing a lot of tiny horizontal lines.

gnuplot's tektronix graphs are quite neat, with a noble "oscilloscope" feeling

If you liked the tektronix emulation, also have a look at sixel graphics [1], which also work in an xterm. Helpful if you are logged in via ssh without X forwarding, and need some graphics...

[1] https://github.com/saitoha/libsixel

Something that I noticed recently is that the latency/input lag feels lower in xterm compared to unicode-rxvt.

I used urxvt from ~2011 until a couple of months ago and I have been really liking the speed and simplicity of xterm since then.

Maybe we have some difference in configuration, but I don't have any perceivable difference between the two - still on urxvt since way back.

Background transparency is the one feature keeping me from considering xterm. I like the URL handling hack in OP, but I'm also a bit married to some urxvt plugins (URL handler, trimming whitespace when copying)

> Maybe we have some difference in configuration, but I don't have any perceivable difference between the two - still on urxvt since way back.

I think the entirety of my ~/.xresources xterm config is

  #include ".Xresources.colors"

  !! xterm
  ! https://invisible-island.net/xterm/
  ! https://linux.die.net/man/1/xterm
  !XTerm.vt100.faceName: Monaco:pixelsize=11
  XTerm.scrollTtyKeypress: true
  XTerm.scrollTtyOutput: false
  XTerm.utf8:    true

  XTerm.vt100.boldMode: false
  XTerm.vt100.locale: false
  XTerm.vt100.scrollbar.width: 8
  XTerm.vt100.scrollBar: true
  XTerm.vt100.utf8: true

I'll try to take a video of the difference at some point — I use xorg 1.20.8 on macOS 11.1 and it definitely feels noticeable when I type quickly with vsync disabled (through Quartz Debug.app).

> Background transparency is the one feature keeping me from considering xterm.

That's fair. The macOS xorg server has never supported the COMPOSITE extension/xcompmgr/compiz, so transparency/compositing have always been out of the question for me.

> I like the URL handling hack in OP, but I'm also a bit married to some urxvt plugins (URL handler, trimming whitespace when copying)

I sympathize with this — I used urxvt for years and grew to like how it could easily extend itself using perl. Thankfully, I have been able to mirror all of my urxvt functionality in xterm since I switched back. It also helped me simplify my ~/.xresources, which shrank from ~300 lines 10 years ago to 50 (for both my xterm and urxvt configs excluding color definitions, which live in ~/.Xresources.colors).

> but we can hijack it to instead scan the screen for URLs and open the browser

For comparison, rxvt-unicode has perl utils for mouse-less URL selection [1]. Since it's operating within the terminal, scrollback is also available for selection (not just the currently visible screen).

After invoking the selection mode, it's as easy as using j/k to choose the URL and Enter to open or y to yank to clipboard. Installed on Arch with the `urxvt-perls` package.

[1] https://github.com/johntyree/urxvt-perls

I have an old laptop that I use to play with Linux and run my home server. It has an not so mainstream ATI integrated GPU and I had a difficult time configuring compton (with i3) to just look good and perform well. With wayland and latest mesa everything just works and is very snappy. It's not perfect though whenever I reboot my machine I have to put my display to sleep first just to make the display work (just shows a blank screen otherwise) but that's a problem with mesa though and nothing to do with wayland.

... if only xterm would support ligatures and colored emojis :)

Alright for font ligatures, but I hope that if they ever support colored emojis those are disabled by default.

https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

Date: Wed 10 Apr 91 08:14:16 EDT

From: Steve Strassmann <straz@media-lab.mit.edu>

To: UNIX-HATERS

Subject: the display from hell

I have a “window system” on my unix box. You see, in the unix world, “system” means “a bunch of unrelated programs.” But that’s not what I want to talk about here today. I want to talk about overlay planes.

My HP 9000/835 console has two 19" color monitors, and some extremely expensive Turbo SRX graphics hardware to drive them. You’d think that I could simply tell X windows that it has two displays, the left one and the right one, but that would be unthinkably simple. After all, if toys like Macintoshes can do this, unix has to make it much more difficult to prove how advanced it is.

So, what I really have is two display devices, /dev/crt0 and /dev/crt1. No, sorry, I lied about that.

You see, the Turbo SRX display has a graphics plane (with 24 bits per pixel) and an overlay plane (with 4 bits per pixel). The overlay plane is for things like, well, window systems, which need things like cursors, and the graphics plane is to draw 3D graphics. So I really need four devices:

/dev/crt0 — — the graphics plane of the right monitor

/dev/crt1 — — the graphics plane of the left monitor

/dev/ocrt0 — — the overlay plane of the right monitor

/dev/ocrt1 — — the overlay plane of the left monitor

No, sorry, I lied about that.

/dev/ocrt0 only gives you 3 out of the 4 overlay bits. The fourth bit is reserved exclusively for the private use of federal emergency relief teams in case of a national outbreak of Pixel Rot. If you want to live dangerously and under threat of FBI investigation, you can use /dev/o4crt0 and /dev/o4crt1 in order to really draw on the overlay planes. So, all you have to do is tell X windows to use these o4 overlays, and you can draw graphics on the graphics plane. No, sorry, I lied about that.

X will not run in these 4 bit overlay planes. This is because I’m using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can’t hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you’re using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly.

So, thinks I to myself cleverly, I shall run X windows on the graphics plane. This means X will not use the overlay planes, which have special hardware for cursors. This also means I cannot use the super cool 3D graphics hardware either, because in order to draw a cube, I would have to “steal” the frame buffer from X, which is surly and uncooperative about that sort of thing. What it does give me, however, is a unique pleasure. The overlay plane is used for /dev/console, which means all console messages get printed in 10 Point Troglodyte Bold, superimposed in white over whatever else is on my screen, like for example, a demo that I may be happen to be giving at the time. Every time anyone in the lab prints to the printer attached to my machine, or NFS wets its pants with a timeout, or some file server threatens to go down in only 3 hours for scheduled maintenance, another message goes onto my screen like a court reporter with Turett’s syndrome.

The usual X commands for refreshing the screen are helpless to remove this incontinence, because X has no access to the overlay planes. I had to write a program in C to be invoked from some xterm window that does nothing but wipes up after the mess on the overlay planes. My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”

Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.

I stopped using xterm because C-h and C-; bindings doesn't work on Emacs. I'm not sure if there's a way to configure it to make them work but I remember trying to look for such settings and gave up. It's easier to just use urxvt.

xterm is sadly very slow (you see line by line re-draw in midnight commander and things like that) on glamor/GPU accelerated Xorg server on all my ARM devices. I switched to st (https://st.suckless.org/) on my ARM devices, and while it has less features, it doesn't have this performance issue.

I never figured why that is, other than it not being a CPU issue.

I believe it is not buffering draws, although have never checked the source.

Edit: I found this at the arch wiki:

    Troubleshooting - Flickering on scroll
    
    Warning: Double buffering may cause non-bitmap fonts to render incorrectly.

    Rebuild xterm using ABS and include the --enable-double-buffer flag:

    ./configure --prefix=/usr \
         ...
         --with-utempter \
         --enable-double-buffer

Could be more friendly.

Hmm, I confused xterm with urxvt.

xterm is still the only usable terminal that supports crisp (bitmap) fonts as far as I'm aware. Which is why I'll be using it until we have high DPI screens everywhere. All the other terminals are unbelievable blurry with their antialiased fonts on ~100dpi screens. (Or alternatively, unbelievably ugly, when turning off antialiasing).

I never understood why so few people are bothered. These blurry fonts hurt my eyes.

This is gold. I think that with a few extra tweaks (sane scroll bars and the like) it might replace rxvt as my regular “lite” terminal.

How can I set an arbitrary background color? I want something like 0x1A1B1C as I have for alacritty.

    xterm -bg '#bebebe'

     xterm -bg \#1A1B1C -fg white

`xterm` lacks Wayland support-- a more secure alternative to X11.

For a fast terminal with Wayland support, check out `alacritty` or foot:

https://codeberg.org/dnkl/foot

`foot` (foo terminal) benchmarks faster than alacritty and offers a client/server mode for even faster startup for new terminal windows.

What about xclock?

Why use xclock when you can use Sun's "clocktool"?

https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

X has had its share of $5,000 toilet seats — like Sun’s Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn’t have enough to tell you the time. Even the vanilla X11R4 “xclock” utility consumed 656K to run. And X’s memory usage is increasing.

This is really dated criticism.

Nobody in 2021 is talking about Sun Open Look. And even that, whatever its faults at the time, was probably less resource intensive than what most HN readers would use to build a UI today. Try running electron on an Open Look era machine.

A tangent but where could I find a good evaluation of Wayland stack (including Weston etc) security? I know the design is often brought up but most vulnerabilities are implementation errors and bugs, and there doesn't seem to be any mention of security (advisories, etc) on the Wayland web site nor does a web search bring up anything that woudl indicate there's any active security focus.

What I'd expect to find is some description of the security guarantees they provide, and some active work (such as fuzzing with hostile clients), and tracking of found & fixed vulnerabilities.

Well, you can read the Wayland book, for instance: https://wayland-book.com/

Of course, security is subject to implementation details. But as far as I know, the protocol is sound, and I can't recall vulnerabilities.

How each implementation handles theirs is up to them. At least, we have multiple implementations of the protocol. With X, not so much.

I didn't find answers to my questions about implementation level security on the wayland-book.com site unfortunately.

Having multiple young codebases implementing the spec doesn't really provide security assurance at this point, though it can have other benefits.

Thanks for foot, I'll check it out. I've been using kitty for now, and I've been pretty happy with it. https://sw.kovidgoyal.net/kitty/

It even comes with a fancy (but rather simple) extension for displaying bitmaps (more efficient than sixel), that I quite like together with ranger.

Does XTerm support unicode?

Yes. And it should be the default if you open an xterm today.

Obviously yes. But depending on your distribution or locale settings you might have to launch the uxterm[1] wrapper instead of xterm if it doesn't work out of the box.

1.: https://invisible-island.net/xterm/manpage/uxterm.html

Reply on news.ycombinator.com