Open davidrg opened 8 months ago
Having thought about it for a few months, I think a simpler solution will be to do a bit of refactoring. At some point I'll have a go at:
Ideally we'd eventually move all the other values that currently live in arrays dimensioned by VNUM to values in the Vscrn struct.
Main advantages of this approach:
If we eventually moved all of the terminal emulation-related globals into Vscrn, then we could support things like ANSI emulation in the command screen as well as multiplexed terminal sessions (TD/SMP over serial, multiple pty channels over one SSH connection, etc).
This is an option for implementing xterms Alternate Screen Buffer (#231). The solution here is to effectively add a second vscrn, VTERM_B, and rename the existing VTERM to VTERM_A.
Both Vscrns share the same event queue, and settings that are applied to one should for the most part also be applied to the other, but they have their own videobuffers allowing us to switch cleanly between them just as we switch between VTERM and VCMD. The alternate buffer, VTERM_B, has no scrollback.
These changes also introduce a new command for controlling the alternate screen buffer - it can be enabled or disabled, and there are hidden commands to force the terminal on to or of off the alternate buffer.
I'm not entirely happy with the scale of the changes here however. Adding a new Vscrn involves adding an additional member to a lot of arrays and its not always obvious which ones should be updated. Having the two VTERMs share some settings and not others, and also share their event queues (even though VTERM_B does technically have its own event queue allocated) is messy and seems a likely source for bugs.
But I don't see a simpler option. We could perhaps instead try just swapping out the contents of VTERMs videobuffer but thats going to involve similar effort keeping the two videobuffers settings in sync and adds some difficulties around disabling scrollback on the alternate buffer, but it does remove the mess around input queues. It is however probably worth investigating this approach in a separate branch just to validate whether this path is indeed the best option.
Before merging: