Live data from Hacker News

Everything you ever wanted to know about terminals

xn--rpa.cc

81–90 of 191 posts

Re: Everything you ever wanted to know about terminals

#81
post #29

You can't have "everything you wanted to know about terminals" with absolutely no mention of terminfo and (previously) termcap. You don't necessarily need ncurses to have a portable smart terminal experience, but you do need terminfo. ncurses magic relies on the lore stored in terminfo, which contains all of the obscure escape sequences and other information about the disparate world of terminals. They're maintained…

TFA does mention terminfo at the very end: > being compatible only with ANSI-capable terminals is a feature, not a bug, go the fuck away. terminfo is a fucking joke. nobody needs to target obscure dumb terminals (or smart terminals, for that matter) from 1983 anymore. I don't have the expertise to opinion on this. But AFAICT most terminals that people still use[1] will self-report as xterm or xterm-256color so they'l…

I routinely use screen in VT100 mode to get basic keyboard escapes for consoles on custom hardware.

Re: Everything you ever wanted to know about terminals

#82
post #28

Off-topic, but it would be nice if HN could properly parse the Punycode encoding of internationalized domain names, so rather than the URL appearing as xn--rpa.cc, it appeared properly as ʞ.cc

Unicode domain names are a security threat, due to homographs.

Upgrade to Firefox and you'll only see the punycode.

Re: Everything you ever wanted to know about terminals

#83

I was working on terminal code recently and had a hell of a time finding anything approaching an authoritative spec or reference docs. The best I found was this: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html I'd recommend that over the wikipedia link in the article, since wikipedia seems to be missing some things.

I don't know about authoritative but this is at least iconic if not definitive http://rtfm.etla.org/xterm/ctlseq.html

This is a great table of control sequences, but the second author cited as maintainer from 1996 to 1999, Thomas Dickey, currently maintains a list at his invisible-island.net site.

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

Re: Everything you ever wanted to know about terminals

#85

I could take this a lot more seriously if capital letters were properly used.

When I see writing like that, I think the author is either German[1], uses IM far too much, or is trying very hard to exude the "edgy teenager" stereotype. The entire site is in that style, and combined with the definitely unusual domain name, makes it very hard to take this person seriously.

[1] apparently an "overcompensation" coming from a language in which all nouns are capitalised.

Re: Everything you ever wanted to know about terminals

#86
post #51

Yeah this is very very far from "everything". Among many things it doesn't speak of ptys. And terminfo, pty, ctty, process groups, and the rendering width of a utf-8 string, and, and and… > i might be one of a handful of people left on earth who actually has the knowledge to Uh, no. Anyone on BBSes in the 90s is very aware of ANSI, thank you. And we've not died off yet. And honestly it's really not that hard at all.…

For a second after I read the title, before I saw the domain, I thought that Linus had written a followup article to his original -- very popular on HN -- one.

https://hn.algolia.com/?query=The%20TTY%20demystified&sort=b...

Re: Everything you ever wanted to know about terminals

#87

Earlier quoted context omitted.

I can’t agree more. An author who can’t be bothered to follow well established forms of style, grammar, and punctuation in a technical article somehow deflates whatever else they have to say even if accurate. It’s not as if they are trying to emulate the works of E. E. Cummings, James Joyce, or Arno Schmidt.

y'all are the most boring people on the planet istg. in the entire legion of internet writers making in depth technical content there is what, one who deviates from the conventions and you can't handle it. This author is a much much better writer than average for free technical content! They have an interesting, unique style! The typography and punctuation are part of that style! It would be tangibly worse if they ad…

The reason it's important to stick to established standards is precisely to avoid discussions like this. It's a total waste of engineering time, so, in this case, be boring.

Re: Everything you ever wanted to know about terminals

#88
My understanding is that control codes for [every possible modifier key combination] + ['standard' US keyboard keys] aren't all standardized.

Is that correct?

I seem to recall having a hell of a time trying to figure out which key combinations Emacs could understand and why (keyboard -> OS -> terminal emulator -> protocol -> program.)

Are there any proposals? Workarounds? Proofs-of-concept?

Re: Everything you ever wanted to know about terminals

#89
post #40

A while ago I was trying to find a way to make my terminal scroll back up after a command executed, so that if the output was long I could read it from the top without having to scroll up manually. There are ways to get yours shell to print something after the command executes, so I just needed to find an ansi escape sequence that would scroll up. Unfortunately I didn't see any sequences that do this. Anyone have any…

vterm in emacs has a command to jump to the previous shell prompt.

Re: Everything you ever wanted to know about terminals

#90

My understanding is that control codes for [every possible modifier key combination] + ['standard' US keyboard keys] aren't all standardized. Is that correct? I seem to recall having a hell of a time trying to figure out which key combinations Emacs could understand and why (keyboard -> OS -> terminal emulator -> protocol -> program.) Are there any proposals? Workarounds? Proofs-of-concept?

> Is that correct?

It's not exactly like that - it's more like there are competing "standards" and interpretations of these standards, and sometimes supporting one means not supporting the other.

Fortunately, such things are rare, and can be addressed by GUI options.

Take for example SGR1 for "bold/intense" text: read the whole issue that came to Microsoft Terminal team in 2018 up to its most recent discussions on https://github.com/microsoft/terminal/issues/109 then check the "simpler" version in wikipedia https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_.28Select... and you will realize there's no "right" answer between bold and bright (or both!), just different preferences and interpretations of the standards.

Post reply on HN