Earlier quoted context omitted.
OK, but you have to admit it does the job and few (none?) people complain about the limitations of VT100 terminal emulation. 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?
I don't know if it's fair to describe this as a limitation of VT100 (and I haven't RTFA yet), but some things that AFAIK terminals don't get right yet: - 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 wo…
The TTY demystified (2008)
11–20 of 33 posts
Re: The TTY demystified (2008)
#12Earlier quoted context omitted.
OK, but you have to admit it does the job and few (none?) people complain about the limitations of VT100 terminal emulation. 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?
I don't know if it's fair to describe this as a limitation of VT100 (and I haven't RTFA yet), but some things that AFAIK terminals don't get right yet: - 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 wo…
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.
Re: The TTY demystified (2008)
#13This 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?
Re: The TTY demystified (2008)
#14Earlier quoted context omitted.
I don't know if it's fair to describe this as a limitation of VT100 (and I haven't RTFA yet), but some things that AFAIK terminals don't get right yet: - 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 wo…
The scrollback buffer problem is annoying, but I just don't think there's a good solution to it. 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 scr…
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.
Re: The TTY demystified (2008)
#15Fantastic! 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…
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.
Re: The TTY demystified (2008)
#16I have read this with interest but the obsessive compulsive developer inside me keeps bothering me with questions like "isn't it worrying/depressing that today's best OS & applications are stuck with interfaces modeled with messy, leaky or no abstraction at all after devices used more than 100 years ago with no opportunity for radical improvement in sight ?". Sometimes I have the feeling that in software we are build…
There are people (Alan Kay et al.) apparently born with Nada's glasses, but industry as a whole doesn't believe them.
Re: The TTY demystified (2008)
#17Earlier quoted context omitted.
The scrollback buffer problem is annoying, but I just don't think there's a good solution to it. 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 scr…
There may not be a good solution currently, but I don't believe that no good solution is possible even in theory. Which makes me wonder if the VT100 paradigm is holding us back. 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 emul…
Re: The TTY demystified (2008)
#18I have read this with interest but the obsessive compulsive developer inside me keeps bothering me with questions like "isn't it worrying/depressing that today's best OS & applications are stuck with interfaces modeled with messy, leaky or no abstraction at all after devices used more than 100 years ago with no opportunity for radical improvement in sight ?". Sometimes I have the feeling that in software we are build…
Re: The TTY demystified (2008)
#19I have read this with interest but the obsessive compulsive developer inside me keeps bothering me with questions like "isn't it worrying/depressing that today's best OS & applications are stuck with interfaces modeled with messy, leaky or no abstraction at all after devices used more than 100 years ago with no opportunity for radical improvement in sight ?". Sometimes I have the feeling that in software we are build…
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.
Re: The TTY demystified (2008)
#20Earlier quoted context omitted.
OK, but you have to admit it does the job and few (none?) people complain about the limitations of VT100 terminal emulation. 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?
I don't know if it's fair to describe this as a limitation of VT100 (and I haven't RTFA yet), but some things that AFAIK terminals don't get right yet: - 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 wo…