Maybe we should fix this for 7.2.0, since it's a recent regression.

If I revert #5954, the screen is not cleared. @kmatch98, I don't immediately see why the terminal gets cleared on restart, but you probably know. Do you see a way to fix this? I thought it might be due an VM object going away, but I don't see that is the problem.

@dhalbert Is there something special with the funhouse display where the upper left corner is not (0,0)? Whenever display.show(None) is executed the terminal is moved back to (0,0). If for some reason the display setting don’t match that, then it could pace the REPL terminal out of view. (See displayio_display_core_show.)

I think the best way to debug is to test on the hardware and boot straight to REPL and check the root_group display element (x,y) locations on the screen and then trigger the bug and see the differences.

Next step if we want to fix the bug will be to understand if there are board settings that need to be looked up to place the elements in the proper location. If you have hints about that, let me know and I’ll take a look.

Unfortunately I don’t have the hardware to test.

@kmatch98 I tested this on a PyPortal, and though the screen does not blank completely on restart, it does erase the error message. Do you have this or a similar board to test?
E.g.:

print("Hello World!")
3/0    # raises ZeroDivisionError

7.1.1:

7.2.0-rc.0:

I think the FunHouse and the PyPortal may differ in the initial rotation. I remember we had to experiment with the display initialization in the FunHouse to get the orientation right.

@FoamyGuy noticed this in his stream yesterday (2/19) -- he was using a PyPortal.
I also see it on a featherS2+FeatherWing TFT 3.5" combo. After the script sets up the display, any error messages are lost.

import board
import displayio
from adafruit_featherwing.tft_featherwing_35 import TFTFeatherWing35

if "feathers2" in board.board_id:
    featherwing = TFTFeatherWing35(
        cs=board.D5, dc=board.D6, 
        ts_cs=board.D21, 
        sd_cs=board.D20)
print("ovo")
3/0

I think maybe the terminal is in the right position but gets the text from it cleared out. If you start using the REPL you do see it begin to show things on the display.

Do the start/stop terminal here result in clearing the text that was previously in the terminal away? https://github.com/adafruit/circuitpython/pull/5954/files#diff-edac12d728f2a3db7c325f4b3d9865f5fe9feb69e34302d626dc2cd11b2bd695R172-R173

Looking into this issue a bit, I commented out these two lines and I do then see the zero division error get printed on the display.

@kmatch98 I did a brief test with split screen REPL / displayio on a build that removes those supervisor_stop_terminal() and supervisor_start_terminal() statements. I was still able to reset_terminal to half the display size, add a Label to the displayio group and move it around on it's half of the display. Everything seemed to behave normally, but I was not super thorough.

Do you think there is potential harm in removing these?

Is it supervisor_stop_terminal() or supervisor_start_terminal() that does the clearing? Can you leave one out? I wonder if you need the supervisor_start_terminal() in case the dimensions change. Maybe it can check if the dimensions are actually changing and only do it if necessary.

Having only one or the other doesn't lead to a better outcome in either case than removing both of them.

With only supervisor_start_terminal() the error message is still not shown. But I don't see other adverse effects at first glance.

With only supervisor_stop_terminal() the error message is also not shown, but the REPL is no longer shown on the display either only the blinka icon and no other text..

As for including supervisor_start_terminal() and supervisor_stop_terminal(), I think I just blindly copied what was already in there when the Display is created.

If we want to keep the old error message around: One thing I noted in the PR (bullet point 4) was whether we wanted to keep the text data in the terminal when we resized it. The challenge with that is that if the terminal is resized, first you have to allocate a new Terminal, then copy the old Terminal data into it, then deallocate the old terminal. Initial discussion in the PR suggested to just start with a clean slate. If we want to keep the data from the previous terminal, I can revisit.

Having only one or the other doesn't lead to a better outcome in either case than removing both of them.

With only supervisor_start_terminal() the error message is still not shown. But I don't see other adverse effects at first glance.

With only supervisor_stop_terminal() the error message is also not shown, but the REPL is no longer shown on the display either only the blinka icon and no other text..

Now I’m remembering stop_terminal deallocates the memory for the terminal and start_terminal reallocates memory for the new terminal. If we leave one or both of these out, we may either cause a memory leak or the terminal may not be the correct size if it was moved or resized.

So perhaps Dan’s suggestion is the simplest solution that will cover 99.9% of use cases: Only reset the terminal if it’s the wrong size.

I thinks okay not to retain the data in the terminal when it gets resized. The user presumably would have intentional resized it so they would understand why it's gone I think.

In the case originally reported here though there terminal isn't getting resized, at least not intentionally I don't think. The user has a code.py happens to raise an exception which stops it executing and breaks out to "press any key to enter REPL". So have not done anything with resizing the terminal.

I do think we want to preserve the terminal text if possible in this case because it makes troubleshooting easier on devices with displays.

My guess is maybe the system is calling displayio_display_core_show() when the exception is encountered in order to switch back to the terminal (assuming user had shown something else) but its appending the error message before doing so and thus it's getting lost when this start/stop occurs.

Ok I’ll take a crack at avoiding the start/stop if the size is not changing.

@kmatch98 If you make a PR, could you make it against 7.2.x? Thanks.

In looking deeper, if we just run supervisor_start_terminal, if the terminal is the same size, it should reuse the tile grid allocation. However, in testing it I see that the tiles get cleared. I've got to dig deeper to see where the tiles get cleared.

Found it, the tiles get reset in the constructor: common_hal_terminalio_terminal_construct. I'll give it a boolean flag to decide whether to rewrite the tiles.

@kmatch98 If you make a PR, could you make it against 7.2.x? Thanks.

I said 7.1.x by mistake. Corrected.

Fixed by #6076