about summary refs log tree commit diff stats
path: root/043space.cc
diff options
context:
space:
mode:
authorKartik K. Agaram <vc@akkartik.com>2016-02-01 13:29:46 -0800
committerKartik K. Agaram <vc@akkartik.com>2016-02-01 13:37:12 -0800
commit07a6418389a6c36c0fe9cded6e585fb013ec90e1 (patch)
tree7c6cd399cc2b741b0befc47023cf264cb4796adb /043space.cc
parent34a2336e41daa20f02f20ae995d6c17ea0b3127f (diff)
downloadmu-07a6418389a6c36c0fe9cded6e585fb013ec90e1.tar.gz
2623 - bugfix: editing sandboxes
If you restore 2 sandboxes, the first render was setting
response-starting-row-on-screen on both, without ever rendering a
response. If the lower sandbox contained a print and rendered the screen
instead of the response, the original response-starting-row-on-screen
was never reset. If the process of running the sandboxes caused the
lower sandbox's title bar to move below the now-stale
response-starting-row-on-screen[1], editing the lower sandbox no longer
works.

[1] (Either because the upper sandbox prints to screen as well (causing
the first F4 to move the lower sandbox down by several lines), or
because a fresh sandbox is created with several lines before the first
F4 is hit.)

Current solution: never set response-starting-row-on-screen during
reload (or otherwise when there's no response).

This is hard to test right now because 'restore' is not a tested
interface, and I can't come up with another situation where the
response-starting-row-on-screen goes stale. So I'm now trying to keep
all changes to response-starting-row-on-screen close together. Another
idea is to add a check that the click row lies below the
response-starting row *and* above the start of the next sandbox. (But
what if there's no next sandbox?)

(This bug is really a regression, introduced last Sep in 2163.)
Diffstat (limited to '043space.cc')
0 files changed, 0 insertions, 0 deletions