Another user that gets frustrated by copy mode's getting the running program stuck from time to time.

> The memory requirement is only 2X: when entering copy mode, duplicate the history buffer. Execution proceeds "in the background" using its own buffer.

+1 with this. It seems to be a very decent solution.

comment #1:

> To me, it's not a bug and screen behaves as expected. When you enter copy mode, you "pause" the output. screen stops reading the output of the slave and focuses on you selecting what to copy out of what has been output up to that point.

You are describing what screen currently does, but what do users expect it to do? Say Bob runs a bunch of code within screen. It stays running even if his terminal explodes. Would Bob expect a feature named "copy mode" to permanently interrupt execution, even after detaching?  Copy mode at least needs an ### EXECUTION HALTED ### banner to communicate its severity.

>
> If it were to still read the slave's output while at the same time letting you inspect and copy the earlier output it would potentially have to be able to store indefinite amount of output.

The memory requirement is only 2X: when entering copy mode, duplicate the history buffer. Execution proceeds "in the background" using its own buffer.

scroll.py:

#!/usr/bin/env python3
import time
with open("/tmp/scroll", mode="w") as f:
    t1 = time.time()
    while True:
        t2 = time.time()
        tdiff = t2 - t1
        t1 = t2
        text = f"tdiff={tdiff} {'!!!!!!!!' if tdiff > 0.5 else ''}"
        print(text, flush=True)
        print(text, flush=True, file=f)
        time.sleep(0.01)

Steps to reproduce:

- Run './scroll.py' in a screen session
- Run 'tail -f /tmp/scroll' in another terminal
- Press 'Ctrl-A ESC' to enter copy mode

After a few seconds, the 'tail' output freezes.  Exiting copy mode generates this output:

tdiff=0.010303020477294922
tdiff=5.808627605438232 !!!!!!!!
tdiff=0.010957002639770508

I think this behavior is a bug, because it violates the principle of least surprise.  Scrolling up or selecting text in a terminal should never block program execution. Screen could be a nice tool for running simple daemons, except that copy mode is basically an outage generator.

What could screen do when the scrollback buffer is full?
1. Kick the user out of copy mode
2. Make a copy of the currently-visible buffer region