Live data from Hacker News

Terminals Are Weird

catern.com

41–48 of 48 posts

Re: Terminals Are Weird

#41
Weird is a matter of perspective. I started programming, on terminals (mostly, for class work - some Apple/Commodore twiddling aside), in the early 80s. Learning about scan codes on PCs in the later 80s seemed complicated to me, because it wasn't what I was used to at first.

If you are used to a remote device that sends and displays characters, then switch to local integrated devices which exchanges much lower level signals to be mapped in software, the new stuff seems strange. Whether or not it's better or worse depends, I guess.

Re: Terminals Are Weird

#42
post #13

I was just thinking about this the other day. To do it, you have to develop a new protocol in order to separate out the control and data planes. I think it would be extremely useful and valuable to start on such a project, but I'm not sure how much interest such a thing would have. I certainly don't agree that Emacs Lisp is the appropriate development engine.

Couldn't that new protocol just be html subset?

Re: Terminals Are Weird

#43

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…

What if you want to switch keyboard layout dynamically?

I normally use a Dvorak layout, but I toggle between that and a UK layout when pairing.

I'd hate to have to bring along my keyboard every time I visit a co-worker's PC, just so I could type in Dvorak on their machine too.

Your way seems like it would also require me to buy an expensive specific Dvorak keyboard just to be able to type in Dvorak. Whereas I get by with a moderately expensive keyboard - with custom unmarked keycaps.

Re: Terminals Are Weird

#44
post #28

Earlier quoted context omitted.

The tty layer handles line editing so that programmers do not have to replicate this functionality. If you write a simple program that obtains commands using "fgets", you automatically get simple editing, and that functionality goes away when the input is redirected from some other device or file. The simple editing is consistent from program to program and maintains the user's preferences. The tty input editing coul…

Well, sure. But in a sane modern architecture that simple editor would be implemented in a userspace app (the terminal emulator would be an obvious candidate) and speak a sane protocol instead of the ioctl madness we have with termios. But it doesn't and it won't, so we all deal with it. But it remains crazy.

Bill Joy's vi (1978) was implemented in user space; that counts as ancient, just a couple of years after the first Unix release. The ioctl madness just has to be applied twice: to change to raw mode input when starting the editor, and then to restore the original mode when exiting or jumping to the shell. The tcsetattr and tcgetattr functions are very easy to use: get the structure, tweak a few things, set the structure.

Re: Terminals Are Weird

#45
post #28

Earlier quoted context omitted.

The tty layer handles line editing so that programmers do not have to replicate this functionality. If you write a simple program that obtains commands using "fgets", you automatically get simple editing, and that functionality goes away when the input is redirected from some other device or file. The simple editing is consistent from program to program and maintains the user's preferences. The tty input editing coul…

Well, sure. But in a sane modern architecture that simple editor would be implemented in a userspace app (the terminal emulator would be an obvious candidate) and speak a sane protocol instead of the ioctl madness we have with termios. But it doesn't and it won't, so we all deal with it. But it remains crazy.

Another thing is that SIGINT interruption (via Ctrl-C or whatever character is configured) and SIGHUP signals wouldn't be reliable if faked outside of the kernel.

Firstly, the tty driver can read and respond to a Ctrl-C even if the application is single-threaded and spinning in a loop, or blocked on some device other than the TTY. If Ctrl-C were handled in user space, then there would have to be a thread through which the terminal I/O goes. Secondly, that thread would have to be completely reliable, and never block or hang for any reason other than reading from the TTY.

Also, a security feature known as a SAK (secure attention key) needs to be in the kernel. A TTY which implements a SAK cannot be entirely transparent.

Re: Terminals Are Weird

#46
post #42
post #13

I was just thinking about this the other day. To do it, you have to develop a new protocol in order to separate out the control and data planes. I think it would be extremely useful and valuable to start on such a project, but I'm not sure how much interest such a thing would have. I certainly don't agree that Emacs Lisp is the appropriate development engine.

Couldn't that new protocol just be html subset?

No.

To clarify somewhat: html is a presentation language.

That's not appropriate for either control or data planes by default.

example- let's define the data plane as an associated list of byte-strings of u8 characters. This covers current common unix pipe usage on the terminal. If we include some lisp syntax for routing & choose to complect some control and data on the command line we then can compose:

`cat thing (. stdout) wc -l ( (. stdout cat) (. sterr echo "error!")`

But, fundamentally, the control plane needs to be asynchronous, so there needs to be a signal handler that a program can listen on that takes a stream of associated-lists with the rough form of:

`(((keys . (control alt del)) (duration . 1000)) ((keys . (alt tab)) (duration . 10)))`

the program listening needs to be able to register with its parent process that it gets a key stream.

anyway. we can work out this system in some level of detail with different representations. The key point is that this needs to be just data addressable easily, without significant difficulty parsing. It also needs to be lossless by default and not dependent upon hacks like timeouts as part of its interface to its consumers. (n.b., it should allow adding as many bucky bits as a keyboard developer wants).

now, if the terminal wants to formally specify as its interface that it takes all output streams keyed by "html-presentation" and render them as html, that seems like a very featureful possibility. I would not write that, but I could see others doing so.

Re: Terminals Are Weird

#47

I totally don't buy the recommendation. If you're going to do something new, you better stop worrying about backward compatibility. ssh and tmux won't work? big effin deal. Those projects would need to grow up in order to keep up with the times. You can't be conservative like that if the goal is to right the wrongs and learn from past mistakes. The road is going to be bumpy but the light at the tunnel would be worth…

"I would like to see some convergence of terminal and windowing-system happening. I initially dreamt of a graphical terminal but then I thought why not go one step further and make it the main interface (so something in the middle of a graphical terminal and a tiling window manager). However I still need to carve out the details."

While I am skeptical about discarding (some amount of) backwards compatibility, I'm very interested in this. Feel free to shoot me an email.

Re: Terminals Are Weird

#48

Earlier quoted context omitted.

"Likewise, a game is prepared to deal with buttons, not semantics. The number and layout of buttons is closely tied with design decisions. A FPS gives you WASD, plus QERF for common actions, ZXC for less common actions, 1234 for menus / weapon selections." Except on my keyboard layout an FPS should be giving me QSDZ, for the same pattern of movement keys, because I'm French and use AZERTY. Or AOE, because I use Dvora…

> Not really, but you take my point... I was simplifying; I don't use QWERTY either. Most operating systems provide two ways to identify key presses, let's call them "key codes" and "char codes". So the char codes on a French layout are QDSZ instead of WASD but the key codes are the same, and the keys are in the same physical location so it doesn't matter. The only difficult part is figuring out how to present key co…

Sure... but regardless you get people with weird keyboards who would still like to play, and most games permit customizing keys.
Post reply on HN