Repository navigation
Do we do the right things when you enter the alt buffer twice? #20840
Description
#20820 has got me thinking.
Terminal
We copy the cursor and some other things from the main buffer again, even if the alt buffer was already active. Is that right?
Conhost
We have a whole other SCREEN_INFORMATION that we just yeet everything into? Are we right?
What is \e[?1049h\e[?1049h expected to do?
Activity
DHowett commentedon Oct 23, 2026
I bet that after #20825 merges we'll do something weird with the cursor, because it's still located wherever it was in the main buffer (which could be off-screen if you resize?)
j4james commentedon Oct 25, 2026
This may be a good time to discuss whether we could possibly replace the current alt buffer implementation with one that's based on VT pages. Basically we'd reserve the last page for the alt buffer, and then switching between main and alt is just a matter of changing pages.
It's a little more complicated than that, but it's mostly a combination of standard functionality:
DECSCto save the cursor state.PPA 6to move to the last page (although we may also want to give ourselves a few more pages to work with).DECRPLto disable scrollback and reflow-on-resize (we don't have this as a mode yet, but that would be a nice addition too).ED 2to clear the screen.DECPCCM(if it isn't already set) to ensure the page is visible._savedCursorStateto the alt version.There is one messy detail that doesn't quite fit, though. DEC pages have individual margin settings, and Xterm buffers don't, so we'd need to copy the margins between pages when toggling the alt mode. Although this isn't a problem for us right now, because we haven't implemented separate page margins yet (pending PR #20523).
But the benefit of this approach is you'd have access to the VT pages while in the alt buffer, which isn't currently supported. This is something that comes up whenever I've tried to convince people of the benefits of paging functionality. They're already using an alt buffer for their full screen app, and they don't want to change that, and that means our VT pages can't be used.
lhecker commentedon Oct 30, 2026
So, if we were to do that, we would essentially call the corresponding AdaptDispatch functions to "shim" alt buffers on top of pages?
Admittedly, that does make me wonder whether it would be too brittle.
j4james commentedon Oct 30, 2026
We don't have to do it that way. That was just an easy way to explain what steps need to be taken without having to go into to much detail.
I also forgot to mention that both Contour and Kermit95 have already implemented alt buffers this way (or at least something like this), so we wouldn't be the first.
But feel free to ignore if you don't think it's a good idea or it's too much effort. It was just something that I've had on my wishlist for a while, so I thought it worth raising while we were discussing alt buffer changes.
lhecker commentedon Oct 30, 2026
I do think it's odd how the flow of data goes Terminal > OutputStateMachine > AdaptDispatch > PageManager, and for pages it continues on into TextBuffer (unidirectional! nice!), but for regular main/alt buffers it suddenly it goes back up and out into Terminal to fetch them.
I feel like, even if main/alt continue to not be pages, this is kind of weird. 😅
As such, I'm actually quite open to your suggestion.
davidrg commentedon Nov 2, 2026
Yeah, when was looking at implementing the alternate buffer in K95 it seemed "easiest" to implement VT paging first, then implement the alternate buffer as a special case of that rather than implement some whole other system that was basically doing a subset of what VT paging already needed to do. So the alternate buffer is just another page with some special rules around it to match xterms behaviour.
Though some of those special rules ended up being to forbid getting to/from the alternate buffer via the VT paging control sequences and prevent DECCRA from copying between the alternate buffer and any other page. Was kind of disappointing to take that functionality away but no other terminal I knew of allows mixing of VT Paging and the alternate buffer like that and K95 is too obscure to get away with defining new behaviours. If Windows Terminal supported doing that though, then I'd gladly delete some code to match!