Live data from Hacker News

Everything you ever wanted to know about terminals

xn--rpa.cc

161–170 of 191 posts

Re: Everything you ever wanted to know about terminals

#161
post #47

Earlier quoted context omitted.

https://www.ecma-international.org/publications-and-standard...

Not all terminal emulators follow that completely. Most only include a subset and some include their own proprietary escape codes too (like iTerm and Terminology have codes for rendering images. tmux has an escape code for changing the session title). Then there's other specs not included in that doc even outside of the aforementioned proprietary codes. Like Sixel, conventions on non-POSIX terminals, etc. Also lets n…

> > ^? is the code for the [DEL] or [DELETE] key on physical terminals, that's why it's an ASCII standard.

> When the PC bucket keyboards came, IBM in their usual idiocy simply put the [BACKSPACE] key where the [DELETE] key normally is, and what's worse, they made it not only move back one space but delete too. Thus came the sadness of everlasting redefining of deletion to be ^H when using a PC bucket keyboard.

Indeed. And to confuse things even further, the [DEL] key on IBM keyboards sends the following ANSI escape sequence: [27 91 51 126]

So we now have 3 different standards for deleting characters (and that's before you start looking at the escape sequences for deleting rows, nor supporting vi and/or emacs/readline bindings).

Re: Everything you ever wanted to know about terminals

#162

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…

  “Oh look, I am a rebel ignoring what they taught me to do in third grade”.  
It certainly is a “style”, cheap.

Re: Everything you ever wanted to know about terminals

#163
post #145

Earlier quoted context omitted.

hTerm and also IIRC kitty have image-rendering escape sequences too.

Not familiar with hTerm. Got a link to the project? Would be good to add support for that to my image rendering library: https://github.com/lmorg/murex/blob/c77b893a58a682735ad7502c...

Upstream: https://chromium.googlesource.com/apps/libapps/+/HEAD/hterm

Fork used by iSH: https://github.com/ish-app/libapps/tree/master/hterm

I looked at the docs (https://github.com/ish-app/libapps/blob/master/hterm/doc/Con...) and it appears to use the same protocol as iTerm.

Here's an implementation: https://github.com/ish-app/libapps/blob/master/hterm/etc/hte...

Re: Everything you ever wanted to know about terminals

#164

The author seems not to be aware of the recent TUI rennaisance[1]. There are libraries like termbox and blessings (python) that are a middle-ground between full ncurses and adding your own ansi codes. There are a lot of modern TUI frameworks like tui-go or tui-rs that bring common GUI conventions back to the TUI (heck there are TUI programming libraries that are designed to be similar to react) - these too tend to be…

Make sure to check out Notcurses! https://github.com/dankamongmen/notcurses#readme demo: https://www.youtube.com/watch?v=dcjkezf1ARY

Now that’s what I call a demo

Re: Everything you ever wanted to know about terminals

#165
post #37

I built a cross platform app to print 'pretty formatted' source code [1]. I didn't want to re-invent the wheel on formatting source code, so looked at all the existing libraries. Originally I figured formatting to HTML, and then building a print-friendly HTML render would work. But this proved super challenging. I tried a dozen HTML engines (including Chromium) but none gave me enough control to render just a single…

> Originally I figured formatting to HTML, and then building a print-friendly HTML render would work. But this proved super challenging. [...] none gave me enough control to render just a single page of the original source file Nothing like as powerful as your app and entirely tangential to the topic of ANSI escapes, but my preferred way to generate HTML from source code is simply: vim +TOhtml +wq +q path/to/source/f…

That is awesome. I've been using vim for years and never knew it had a command for this. I guess I should do more spelunking through the docs. Thanks!

Re: Everything you ever wanted to know about terminals

#168

off topic but I would love a version of this with a more "plain" colors/ punctuation/formatting. finding it very hard to read / navigate anyway the content looks good so will try to find time to sit down and read this "essay" soon

I see these comments on many links from here. There are extensions or reader mode in your browser. At least that would take care of the colors. In Vivaldi there are additional 'Page Actions' to turn a page to gray scale etc.

Re: Everything you ever wanted to know about terminals

#169

Here is something I learned only several weeks ago. While working on Pipe Watch, I strayed into reading the standard. * The ESC [ command start sequence is actually a compromise for 7 bit systems. The [ character is not chosen by accident. It has an obvious positional relationship to ESC in the ASCII code which is why, informally, Ctrl-[ is the same as ESC. * If you have an 8-bit-clean channel to the terminal, only a…

> If you have an 8-bit-clean channel to the terminal, only a single character is required: the "upper escape" from the C1 control character set (0x80 to 0x9F). I'd avoid using this. It conflicts badly with UTF-8's use of 0x80 through 0xBF as continuation characters.

I don't entirely buy the argument because in a regular ASCII control sequence like ESC[5A, you have the same problem. All those characters have a role outside of the signaling, so if either side is in an unexpected state, they get misinterpreted. This is just the risk of in-band signaling.

Of course, if the terminal is ignorant of UTF-8 then this is a nonstarter, because whenever CIS occurs as a continuation byte, it will be misinterpreted. If the terminal is ignorant of UTF-8, why would you send UTF-8 to it, though? If it's going to be interpreting UTF-8 as some branch of ISO Latin, the display will be a mess.

If the terminal and host do handle UTF-8, then this CSI signaling is just an extension of the state machine. It's also nice and simple that, in the absence of any data loss or synchronization error, the CSI code is unambiguously not part of any valid UTF-8 character (except as the second or subsequent byte where the receiver is in the right state to interpret it that way).

In my experience, it's the terminal->host direction where you get mixups, whereby the terminal generates some escape sequence like for an arrow key, but the host is not in the right state, and interprets part of it as data. This is exacerbated by a situation in which the host supports ESC as a UI command. CSI solves the abmbiguity between the control sequence start and ESC just being ESC.

Re: Everything you ever wanted to know about terminals

#170
post #121

Earlier quoted context omitted.

It looks like you have done a lot of work with sixels based on your github too. Have you ever written anything about that?

Not just sixels but she also has the most superior tool for rendering images as unicode blocks. https://github.com/csdvrx/derasterize

oh hello there :)

To be fair it was more like a joint venture between us!

Post reply on HN