Open TimonPost opened 5 years ago
Given the fact that a single alternate screen behavior is baked into xterm, one possible option is to create various Read/Write buffers and update the alternate screen based on what is stored. This would effectively emulate multiple "screen"s by then having the user select which "buffer" to render. This might be less of a library concern rather than a user implementation consideration. Or did you have something else in mind?
No that is a good solution, I was thinking of that as well. We can mimic the behavior of output, input, error streams.
Task Description
A terminal has screen buffers to which you can write. Buffers are separated from each other and won't change one and other contents. The main buffer is visible by default. We can go to the alternate screen by using the 'crossterm_screen' crate. When we change stuff on the alternate screen nothing will change on the main screen and in reverse.
This is all nice and well, however, we are limited to the main, and alternate screen. And can't have a second alternate screen. I want cross-term to allow controlling multiple screen buffers.
Task Todo
Notices
Windows allows us to easily support this because with winapi you can create a new screen buffer and make it the active (visible) one. Research needs to be done to accomplish this with Linux.
This functionality should be placed in the
crossterm_screen
create.