Hacker News Reader

Comment by andrewla | Hacker News Reader

Yes, this is one of the avenues that I've chased down a bit.

One problem is termcap/terminfo itself. The definition has expanded greatly over time, and documentation is poor to non-existent. In many cases termcap/terminfo has been implicitly extended to support ncurses specifically. And like you say, everyone just sort of assumes ANSI/xterm -- nobody has `PS1="$(tput setaf 3)\w $(tput setaf 0) $", you just hard-code the codes.

The last time I chased the rabbit down this hole I got mired in TTY-land and was not able to dig myself out. Too many insane layers, and before you know it you're writing code to emulate serial connections in a vain attempt to make things work without burning the whole world down.

Both (n)vim and tmux have internal TTY emulation as well which makes things even crazier; I think vim uses libvterm and tmux has one internally hand-coded. It's a mess.

View on HN

tmux, screen, emacs, and vim all have terminal emulators in them because it’s required, not because they’re crazy.

Consider a really simple case. You are using screen (or tmux, or emacs, or whatever) and you have your terminal divided in half so that you can use a program in one half and tail a log file in the other. The program sends a ^L to clear the screen. Screen (or tmux or whatever) must read the ^L and then _not_ send it on. If it sent it on, the whole screen would be cleared, not just the half with the program in it. Instead it has to send whatever control sequences would erase the text from just the right portion of the screen while leaving everything else alone. Virtually everything sent by the program(s) has to be intercepted and reinterpreted in order for it to work right.

Amusingly, FF is almost never the control character for clearing the screen. The idea that it is, is widespread, and attributable to some home computers of the 1980s. But it was never the case for DEC VTs. It's equivalent to VT.

I agree with your overall point but your example isn't a great one because ^L would be handled by the controlling process regardless of the terminal state. You don't need any special magic here. And blanking specific sections of a screen wouldn't need any special magic unless you're launching other processes and forwarding their output to the terminal. But if you're not forwarding the output of other processes then you can use standard ANSI escape sequences (or even just \s) to blank specific parts of the screen.

\s is a bit hacky for blanking though, it can produce some undesired results in terms of copy/pasting from the terminal and resizing. But if you've got a "full screen" process like you're describing, you'd be trapping SIGWINCH for resize events anyway.

Since I'm getting downvoted so I'll evidence my point a little more:

Bash source for the ^L hotkey: https://git.savannah.gnu.org/cgit/bash.git/tree/lib/readline...

Notice it's calling termcap:

     _rl_clear_screen (0);  /* calls termcap function to clear screen */

So lets look at what termcap does:

    $ tput clear | hexdump -c
    0000000 033   [   H 033   [   2   J
    0000007

Which isn't the ASCII character ^L (0xC) but instead an ANSI escape code (CSI sequence, to be exact) https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_...

The actual ASCII character for ^L is form feed, (FF: https://www.ascii-code.net) which does serve a similar function but designed for old printers: https://en.wikipedia.org/wiki/Page_break#Form_feed

It doesn't actually clear the screen on modern TTYs. You can try this yourself:

    $ printf "\f"
    
    $ awk 'BEGIN{printf "%c", 12}'
    
    $

Notice how each time it's effectively doing the same as \n?

So in conclusion, ^L clearing the screen isn't something built into the TTY. It's just a hot key like ^U.

There are some hot keys are are driven by the TTY though. ^C, for example. When you press ^C you're not actually sending the 0x3 ASCII character to the controlling process, your TTY gobbles that up and sends a signal to the controlling process instead (albeit this behaviour can be changed by altering the TTYs mode, which requires making a SYSCALL).

So here we've discussed ANSI escape codes, signals and SYSCALLs. However none of these interactions are ASCII characters despite how they're depicted in printed media. Suffice to say, terminals are complicated :)

No, they're crazy. I already have a window manager I like; I don't need my terminal to implement their own half-assed one, and my multiplexer (running on the terminal) to implement their own half-assed one, and my editor (running on the multiplexer on the terminal) to implement their own half-assed one.

So don't use tmux then. The entire reason most people use something like tmux is because they want a window manager in their terminal.

This is one of the great joys of FOSS, if you don't like a terminal-based utility then you can bet there's a dozen other options available for you to use.

  > No, they're crazy. I already have a window manager I like; I don't need my 
  > terminal to implement their own half-assed one,

Basically agree, though note that ssh and dtach and similar tools need to create pty's on the server and client ends because they implement essentially an adapter between a tty and a byte stream.

If you really want crazy, run `xterm -ti 340`, then run run an X server from the xserver-sixel repository <https://github.com/saitoha/xserver-SIXEL> in it. Now y ou can run as many terminal emulators, complete with real truetype fonts and all the colors you could want, inside the one terminal. Use a tiling window manager and you’ll be able to avoid using tmux entirely.

Terminal multiplexers like tmux need to create a pseudo-TTYs otherwise they couldn’t multiplex your terminal.

My shell also creates PTYs on some rare occasions too. I’d prefer not to because it’s messy but sometimes there’s no way around it if you want your command line applications to behave like they would on a TTY whilst still having your utility capture that applications output as if it were writing to a pipe.

This is a limitation of TTYs.

The most annoying part of it all is that creating a PTY differs from one Unix-like OS to another. So it’s definitely not a rabbit hole developers go down happily.

> Terminal multiplexers like tmux need to create a pseudo-TTYs otherwise they couldn’t multiplex your terminal.

[Edit: I misread the parent comment as saying multiplexers needed to do terminal emulation. Dtach only multiplexes (using pesudo-TTYs, of course) but unlike screen or tmux does not do terminal emulation. Original comment follows:]

That isn't strictly true; the one I use (dtach) is just a multiplexer.

dtach creates pseudo-TTYs too:

- https://github.com/crigler/dtach/blob/master/master.c#L53

- https://github.com/crigler/dtach/blob/master/master.c#L108

As an aside, that projects source is surprisingly easy to follow. I was able to grok it in just a couple of minutes. Kudos to the author.

Yes, I misread your comment, sorry, having had my mind stuck on terminal emulation.

A PTY is an intrinsic part of terminal emulation.

I think what you’re alluding to is that tmux gobbles up escape sequences (which is configurable by the way) and tracks cell positions. But as I said in another comment, the value add of tmux is its window management capabilities. That’s precisely why people like myself use it. And you cannot have that without complexity. In some edge cases that complexity causes issues, but on the whole I’m more productive for it.

Saying it’s stupid that tmux does that is like saying it’s stupid that motorbikes have gears and fast patrol engines when a bmx works just as well. Sure, to someone who’s never seen a bike before they both look similar. But don’t be fooled by the fact that they both have 2 wheels because they cater to very different needs, hence their very different engineering designs.

Reply on news.ycombinator.com