Dropping AlternateScreen breaks alternate screen mode with Crossterm instance about crossterm HOT 4 CLOSED

It turns out it is possible to stay in raw mode by calling disable_drop() on AlternateScreen's Screen like so:

...
{
        let mut alternate_screen = screen.enable_alternate_modes(raw_mode).unwrap();
        alternate_screen.screen.disable_drop();
        crossterm = Crossterm::from_screen(&alternate_screen.screen);
    }
    // <-- Dropping alternate_screen here
...

However this feels like a bit of a hack. Alternate screen mode still breaks after the drop.

from crossterm.

1. It is 'normal' behavior for an AlternateScreen to be switched back to mainscreen when it is dropped. AlternateScreen is meant for quickly doing something and not have it open for a long time. So, for now, you are bounded to the scope in which you are allowed to use the alternate screen.
2. When Screen drops it will turn off the raw modes. There are usecases you don't want that from automatically happening so, therefore, you can call disable_drop().

In the future, this might be more flexible and I will build in the functionality to have multiple screen buffers who have their own settings. You can be using lazy_static this allows you to have your crossterm type living longer.

I get your argument that the user might be misled and I take a look to see if I can improve the docs here. Are there any problems you are encountering with otherwise I'll close this issue.

from crossterm.

Thanks for the quick reply. I think AlternateScreen's behavior make sense and isn't the issue here. What threw me off is that if I create a Crossterm instance from an AlternateScreen's screen, the Crossterm instance 's behavior depends on whether the AlternateScreen has been dropped or not. I'm not very familiar with your code, but it looks like AlternateScreen and Crossterm share ownership of the TerminalOutput via Arc's, so they can both mutate it at will. In the worst case scenario you could create a Crossterm instance from an AlternateScreen's screen, send the AlternateScreen to whatever thread you like and use it to manipulate the screen, until you eventually drop it. The Crossterm could be doing the same in a completely different part of your code and work as expected, until the AlternateScreen drops and the behavior suddenly changes. It would be extremely difficult to figure out where this change comes from without going through the source, because it has nothing to do with what you do to the Crossterm locally.

Given that Crossterm seems to be a convenience wrapper, could it consume an AlternateScreen so that there's only one place to change behavior? Alternatively, could Crossterm retain a reference to AlternateScreen, making sure they're used in the same place?

Edit: Consuming the AlternateScreen seems preferable because the lack of self-referential structs means the AlternateScreen and Crossterm couldn't be held in the same struct.

from crossterm.

closing this, because it is answered if you have any more question feel free to reopen.

from crossterm.