The TTY demystified (2008)
linusakesson.net
linusakesson.net
http://arstechnica.co.uk/information-technology/2015/08/surf...
If we could start from scratch what would a contemporary TTY be like? Would it be better in terms of functionality, multi-platform capability? What would be the advantage?
- Screen's scrollback buffer and my terminal's scrollback buffer don't know about each other. If I swap screen tabs frequently, my terminal scrollbar becomes useless. OTOH, if I use a tabbed terminal, I'm guessing it would use a different VT100 in each tab and that wouldn't work very well with screen.
- I'd like to be able to drop a marker in my bash prompt, and easily scroll back to the top of the previous command.
- For that matter, I'd like to be able to selectively hide the output of previous commands, and when I want to look at it again I'd like to be able to view it in less instead of just unfolding it in-place.
Possibly I'm rare, but I'm frustrated very frequently...
screen (and tmux) basically store their own scrollback. The advantage here is that you can then page through the line history on another terminal or even another computer. The downside is that that your terminal (xterm/iterm/whatever) has to decide what to show when you page up. It has no way to read screen's internal scrollback, so it can either show you old non-screen lines, or hide the scrollback entirely. Switching into/out of screen will just add to the confusion.
(I think some terminals will hide the scrollback history when they spot the TTY in curses-style mode, and only bring it back when that process quits?)
One other annoyance for me is the behaviour of scrollback with a command like 'less' or 'more'. If you are paging down through a file, then scroll back up, some terminals will show you earlier lines of the file you are viewing, while others show you 'pre-less' scrollback.
Like, if a VT100 understood the concept of tabs natively, it seems like this wouldn't be a problem. Screen could just map its windows onto VT100 tabs, and the terminal would know what to do with that.
I don't know if adding tabs to VT100 emulators would be remotely feasible, or a good idea if it was, but I expect there's something in this space that would be an improvement on what we have.
https://www.destroyallsoftware.com/talks/a-whole-new-world complains about the limitations of VT100 and has some ideas for (GUI) terminal improvement.
It'd be a monstrosity written in javascript with merely adequate performance on an i7 and no backwards compatibility.
There are people (Alan Kay et al.) apparently born with Nada's glasses, but industry as a whole doesn't believe them.
I had to add the word "probably" to the above statement because I have not actually tried disabling the TTY subsystem in OS X and verifying that all the apps typically used by non-programmers continue to work normally.
Moreover, when our typical Mac user visits a web site, probably nothing goes wrong if the TTY subsystem on the web server is absent or disabled. (Of course, the administrators of the server will not be able to ssh into the server, but these days, a significant fraction of web servers are adminned using methods that do not rely on anyone's being able to ssh into the servers.)
I kind of agree with parent, though: during my more obsessive moments I do get worried / depressed that a large fraction of programmers are still reliant on software reliant on the TTY abstraction. Although I appreciate minimalist software and software ecologies consisting of many small tools (each of which does one thing well) as much as the next programmer, I would have expected that in 2015 there would be popular minimalist software ecologies not reliant on the TTY abstraction.
I will end my comment with 2 paragraphs designed to prevent nitpicking replies:
Yes, I know that Plan 9 is a minimalist software ecology not reliant on the TTY abstraction. Since on its best day, back when Bell Labs' Computer Systems Research Group ran Plan 9, Plan 9 almost certainly had fewer than 500 users, I would not call Plan 9 popular, however.
I do not dispute that the TTY abstraction remains the natural and the best tool for certain peripheral tasks, e.g., driving serial ports, which continue to have their uses, e.g., in hardware hacking because serial ports are so vastly less complex than something like USB.
When I wrote my comment I was reacting to what I thought your point was: that the console itself might be obsolete and that we should just use binary protocols or some such. Now that I've read some more comments and watched the Destroy All Software video linked to in another comment I think I understand your point better.
In my day job I write software for archival preservation of digitized cultural materials, so I tend to think in terms of preserving access for generations. In this context the continuance of the whole UNIX model makes my job easier. I really really want for computers in the coming decades to be able to interact with, or at least emulate, my software and data.
I can see the limitations and of the TTY as implemented. I still think we need to preserve textual middle layer(s) and UIs, both for historical reasons and because those layers are very useful. I'm guessing we probably both agree about that.
This comes at a good time for me -- I'm getting interested in TTY emulation.
Currently on a learn-Emacs kick. Every couple of years I start using it then back off due to general cruftiness. However, it is undeniably featurefull, and the idea of just learning one last editor rather than a bunch of half-baked ones is appealing.
What about embedding Emacs, through a TTY interface in whatever new fancy cool TM editor experiment you want?
Good luck with the emacs learning. I've been a user for years and have barely scraped the surface of its features. Luckily, you don't need to be an expert in emacs for it to be a good editor.
Then there's X-Windows, which was explicitly designed as a terminal system. There were special-purpose X-terminals once.
In the phone space, things are less terminal-like. Although, amusingly, the interface to the phone modem usually accepts the Hayes AT command set.