Hacker News Reader

Comment by philh | Hacker News Reader

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 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.

View on HN

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 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.

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 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.

Eh. A real VT100 should understand tabs, you can set them with 'Esc H' oddly the DEC manuals don't say what the effect of resetting tabs would be (I'd guess it defaults to multiples of 8 characters).

Not \x08 tabs, but tabs like recent firefox and chrome use (as if you had several terminal windows with separate ptys and screen contents, but all in one window-manager window).

Italics. And even worse (because it is more common), bold. Hey, let's throw in "I want to have something bold and italics and this colour".

Possibly I'm rare, but I'm frustrated very frequently...

That isn't the terminal, though, that's the software using it. A VT100 could be made to do any of that.

Try the new iterm2 beta. It does the first two items in your list (tmux integration and shell integration)

Reply on news.ycombinator.com