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.)

1 files changed, 1 insertions, 1 deletions

diff --git a/029tools.cc b/029tools.cc
index fb52c7b4..7090abda 100644
--- a/029tools.cc
+++ b/029tools.cc
@@ -324,6 +324,6 @@ case _LOG: {
   for (long long int i = 0; i < SIZE(current_instruction().ingredients); ++i) {
     out << print_mu(current_instruction().ingredients.at(i), ingredients.at(i));
   }
-  LOG << out.str() << "(length: " << get(Recipe_ordinal, "length") << '/' << contains_key(Recipe, get(Recipe_ordinal, "length")) << ")\n";
+  LOG << out.str() << '\n';
   break;
 }