Live data from Hacker News

Terminals Are Weird

catern.com

1–10 of 48 posts

Re: Terminals Are Weird

#3
This, like many things, is a case where many different problems get complected, because no one is able to step back and tweak every level of the stack to cleanly separate out the relevant models/abstractions.

Ideally, a computer keyboard would be able to directly send both an arbitrary number of named control functions, and arbitrary unicode text (either as full strings or as code units one by one). Instead though, keyboards (in every existing keyboard protocol) send a very limited number of scan codes, and what to do with those is left entirely up to the operating system. Thus the operating system can’t just get a symbol from a foreign-language keyboard and know what to do with it, but needs to be put into a special mode depending on what keyboard is plugged in. If multiple keyboards are plugged in with different language layouts, too bad: at least one of them will not behave as expected.

Then at every level of the software stack, from the low-level device drivers, up through operating system services, to end user applications (e.g. browsers or terminals) and then on to custom behavior running on those applications/platforms (like a webapp or whatever), everyone gets to take a whack at the meaning of the keyboard code. At each level, there’s logic which intercepts the keyboard signal coming in, digests it, and then excretes something different to the next layer.

As a result, it’s almost impossible for application authors (much less web app / terminal app authors) to know precisely what the user intended by their keystrokes. And it’s almost impossible for users to fully customize the keyboard behavior, because at several of the levels user access is impossible or difficult (especially in proprietary operating systems, or in locked-down keyboard firmware e.g.), and even where users do have access, it’s very easy to make a minor change that totally screws something up at another level, because none of the relevant abstractions are clean.

Furthermore, custom user changes at any of these levels are almost never portable across applications, operating systems, or hardware devices. Every change is tied to the specific hacks developed in a particular little habitat.

Overall, a very disempowering and wasteful part of the computing stack.

Re: Terminals Are Weird

#6

All the devices from pre 80s era are 'funny' because they conflate everything inside the implementation.

It’s not like we’re doing any better with the client-side web development stack (to take one example).

Building simple composable abstractions and systems is just really hard, and takes a lot of practice and refinement. Unfortunately, programmers don’t necessarily get much practice before their designs become the foundation on which everyone else needs to work (for example, there is very little emphasis placed on designing effective software abstractions in academic computer science programs), and there’s often no easy way to go fix the defects afterward.

Re: Terminals Are Weird

#7
"If you do still want or need to make a terminal application that is interactive rather than just being a command-line tool, what is the best way to go about it? You should write it inside Emacs, using Emacs Lisp, and run it as an application by invoking Emacs to run the function that is the entry point for your application. This way you can have legacy terminal support to make use of ssh and tmux, by running Emacs in a terminal, and modern graphical support to display fancy graphics and use more keybindings, by running Emacs in a graphical environment."

Though the latter point is interesting, I find the suggestion unexpected. Isn't curses-based applications a possibility for the author? Why would you limit your users to those that use Emacs, unless the application is just for you?

I'm working on a ClojureScript on Node.js (i.e. instant boot) functional UI library[1] and I find it pretty empowering. I also kept the Node.js touchpoints very separate so I can soon provide a JS Canvas implementation so the same UI code runs on terminal and browser for free. I was suprised how easy it was to implement vi/Emacs-like sequence keybinds, with prefixes and all that. I'm really liking the ability to easily whip up terminal user interfaces for various simple and complex applications.

1: https://github.com/goldfeld/i9n

Re: Terminals Are Weird

#8
The summary of this well written page is:

  If you do still want or need to make a terminal application
  that is interactive rather than just being a command-line 
  tool, what is the best way to go about it? You should write  
  it inside Emacs, using Emacs Lisp...

Re: Terminals Are Weird

#9

...and here is a good historical perspective on the whole subsystem, which could explain why terminals are weird: http://www.linusakesson.net/programming/tty/

Not only why, but also how they work in some more detail. Only after reading this I understood, for example, why C-u works in the terminal even if right/left arrows do not in this particular moment (like after using read builtin or cat without arguments). Very good read.

Re: Terminals Are Weird

#10

This, like many things, is a case where many different problems get complected, because no one is able to step back and tweak every level of the stack to cleanly separate out the relevant models/abstractions. Ideally, a computer keyboard would be able to directly send both an arbitrary number of named control functions, and arbitrary unicode text (either as full strings or as code units one by one). Instead though, k…

That's a bleak outlook to have. Like the author said, you can always just go for graphical toolkits and ignore terminals. Whereas, embracing unix and terminals, I personally find it an empowering and frugal part of the computing stack: predictable, works everywhere, light and simple. Limiting factors can be a positive thing.
Post reply on HN