What is Reddit's opinion of xterm?

From 3.5 billion Reddit comments

When I saw the title, I thought it was going to be about someone who embedded some xterm escape sequences in a binary that remapped the space bar into "rm -rf *<enter>". (I'm not entirely sure there are xterm escape sequences to remap keys but there sure are a shitload of strange things you can do.) But the described problem is much worse.

Edit: and now that I think about it, the escape character in the escape sequence probably wouldn't be printed by strings anyway as it's a non-printing character, so that doesn't even make sense.

The feature you're talking about is the "alternate screen buffer":

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-The-Alternate-Screen-Buffer

...and it's a feature of xterm. top invokes that before it starts to tell the terminal emulator, "give me a separate screen to which I will write my output" and later when it quits it toggles the alternate screen buffer back to what it was telling the terminal emulator, "restore what you had previously."

Here's some code I wrote to handle that functionality:

https://github.com/liftoff/GateOne/blob/master/terminal/terminal.py#L3493

=)

I would assume it happens because some of the characters coming from random result in valid command sequences. Pretty sure there are things there to change the text encoding values for your terminal.

Yes, quite magic. I got it by running this

$ script Script started, file is typescript $ setterm --inversescreen on $ ^D Script done, file is typescript

Then in typescript:

$ setterm --inversescreen on ^[[?5h $ ^D

Escape sequences are here to talk to the terminal.

• some can change the colour of what will be printed, like \033[31m for red text
• some alters the properties of the terminal, like \033]0;TITLE HERE\007, or \033[?5h.

Long list here: http://invisible-island.net/xterm/ctlseqs/ctlseqs.txt

But you can have some of them with the scrpit method (package util-linux).

> Constructive criticism is also welcome!

I don't think I could criticize the software itself without trying a project with it, but can I critique the description? I thought it was pretty confusing that it's called a terminal emulator. See exhibits:

• Terminal

• Terminal Emulator

A few months back somebody was posting here about an idea they had for a terminal emulator for games, which would have features like popup menus for the game to use. From the description, I thought Zircon might be something like that.

I can't think of a standard name for this sort of thing, but "simulated terminal" sounds good to me. BearLibTerminal uses "pseudo-terminal" which also sounds good.

I don't consider the UI of a terminal complex, particularly. I use xterm 99% of the time and don't imagine I'll be switching to something with more UI elements any time soon. I don't really want menus and tabs and scrollbars and such.

I do consider the UI of a terminal "dear and important", since it's the conceptual space where I do a huge portion of my work. Giving me my shell and getting out of the way sounds simple in principal, but the details matter a great deal and very few implementations get things right to my satisfaction.

It's worth observing that for a terminal to really behave correctly, it has to cope with decades worth of sometimes-maddening convention and behavior on the part of a lot of other software. Give this xterm FAQ or this changelog a skim for some examples of what that means in practice.

Probably the most important resource to me was invisible island. We kinda just jumped into the deep end with WSL and started trying to run linux binaries before the terminal was able to support them. We started with VIM and tried to get that to run, and that gave us a long list of sequences we had to look up how they worked, experimented with on a VM, and then recreate the behavior in conhost. Then we tried emacs, then tmux, each step of the way learning more about certain assumptions we had made, and more edge cases.

If there's a book out there that actually describes some of the quirks of VT sequences in a sensible way, then I'd be very interested to see it too (and maybe a little disappointed I didn't find it earlier :P)

> If you know for sure that this isn't possible, I'd also really like to know. I can try to use a different input system. If you have suggestions about any methods to achieve what I'm looking to do, I'd be very grateful.

I'm not aware of curses being capable of doing this for key events, and I've done a fair bit with both ncurses and PDcurses. But the best authority on that would be Thomas Dickey himself: there might indeed be some trick that works in conjunction with xterm. That said: mouse presses and releases can be captured independently, but only for a relatively recent xterm-compatible terminal, and it might not work with PDcurses.

I would suggest either living with the keyboard repeat rate as set by the OS (remember: ncurses apps are supposed to run OK even with < 9600bps serial links), or looking into SDL and only using X11, Win32, or Quartz, i.e. no real text-mode console.

One other thing: DECARM (ESC [ ? 8 {h | l}) can be used to turn on or off the keyboard repeat rate (but not change it). X11 emulators might respond to this. It looks like xterm does not:

> The only VT102 feature not supported is auto-repeat, since the only way X provides for this will affect all windows."

> http://www.xfree86.org/current/ctlseqs.html (this one especially)

That appears to be a bit out of date. I think this is the xterm that's commonly used in distributions:

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

Keep in mind that while most terminals mimic Xterm in some respects, none of them implement all of Xterm's features and control sequences -- meaning some of this will work in other terminals and some won't.

Your question makes no sense. Xterm supports 256 colors by default:

pkg info xterm

xterm-318 Name : xterm Version : 318 Installed on : Sat Aug 8 15:00:01 BRT 2015 Origin : x11/xterm Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : x11 Licenses : Maintainer : WWW : http://invisible-island.net/xterm/ Comment : Terminal emulator for the X Window System Options : 256COLOR : on DABBREV : off DECTERM : off GNOME : off LOGGING : off LUIT : on NEXTAW : off PCRE : off SIXEL : off WCHAR : on XAW3D : off XAW3DXFT : off

Run vttest for a brief overview, and read ctlseqs.html for more.

Although not all the features it tests for are necessarily useful, many of the failures are utterly disgraceful.

I think I saw mentioned somewhere that you had to enable ReGIS support at build time.

Throughout 2014 work was done on the ReGIS support. I'd head on over to http://invisible-island.net/xterm/ and grab the latest version and compile it yourself. How well it will work, I have no idea.

Konsole is pretty shit compared to urxvt. Most everything is pretty shit compared to urxvt. Though urxvt isn't the most user friendly to get set up right, but having used just about everything out there, there's nothing I like more. Highly configurable and extensible, provably faster than everything else, and supports more vt100/xterm sequences than anything else, with the exception of xterm itself.

Very small demo http://i.imgur.com/qiN4qP8.png

Also note that I can't set the terminal title from the terminal in konsole. quite a bother when I have a few windows open.