Re: range_line_is_continued

[rivenirvana]

This has been bugging me for a bit, so I figured I'd post this as a discussion first since it might not be an issue after all.

Was trying to update my last PR about cmd paging, and hit a test fail which made me think I'm misunderstanding this function. So just to clarify, am I correct in my interpretation that:

• range_line_is_continued basically checks if the line above the specified line is wrapped (next_char_was_wrapped == true at the end of that line)
• meaning that the specified line is the "start" of a new line (if returned false)
• or the specified line is a continuation of the preceding line (if true)

Just experiencing some confusion, because when I rigged the lvco codepath in find_cmd_output so that I can easily see in the test assert errors which line range_line_is_continued returns true for, I'm getting inconsistent results. I'm probably missing something here.

Maybe there's something inconsistent about setting wrap markers on resize (specifically for lines that don't get wrapped at all)?Or maybe it's a wrong assumption that I can just skip over continued lines for this feature (since i'm only looking for prompt and output markers). Will try to have a look again at the resize code, but my currently sleepless brain will appreciate any guidance, thanks.

[kovidgoyal]

yes it means the last cell on the prev line was marked to be wrapped.

[rivenirvana]

Bumping this again in the hopes of getting it properly closed.

As a follow-up to #8488, I had a small snippet I was planning to include as well, but couldn't due to prompt_marking test failing. Can I request you to take a quick look at it? I thought it was a pretty harmless change, am I incorrect?

diff --git a/kitty/screen.c b/kitty/screen.c
index 5c57140b6..6a7f49ea9 100644
--- a/kitty/screen.c
+++ b/kitty/screen.c
@@ -4106,6 +4106,10 @@ find_cmd_output(Screen *self, OutputOffset *oo, index_type start_screen_y, unsig
         // find around: only needs to find the first output start
         // find upwards: find prompt after the output, and the first output
         while (y1 >= upward_limit) {
+            if (range_line_is_continued(self, y1)) {
+                y1--;
+                continue;
+            }
             line = checked_range_line(self, y1);
             if (line && line->attrs.prompt_kind == PROMPT_START && !range_line_is_continued(self, y1)) {
                 if (direction == 0) {
@@ -4130,6 +4134,10 @@ find_cmd_output(Screen *self, OutputOffset *oo, index_type start_screen_y, unsig
     // find downwards
     if (direction >= 0) {
         while (y2 <= downward_limit) {
+            if (range_line_is_continued(self, y2)) {
+                y2++;
+                continue;
+            }
             if (on_screen_only && !found_output && y2 > screen_limit) break;
             line = checked_range_line(self, y2);
             if (line && line->attrs.prompt_kind == PROMPT_START) {
@@ -4139,11 +4147,6 @@ find_cmd_output(Screen *self, OutputOffset *oo, index_type start_screen_y, unsig
                         break;
                     }
                     found_prompt = true;
-                } else if (found_prompt && !found_output) {
-                    // skip fetching wrapped prompt lines
-                    while (range_line_is_continued(self, y2)) {
-                        y2++;
-                    }
                 } else if (found_output && !found_next_prompt) {
                     found_next_prompt = true; end = y2;
                     break;

Quick link (github doesn't accept it as .patch): test.txt

As for why I bring it up in this thread, I think it's related.

• test_prompt_marking fails, with an AssertionError: '0wrapout\n0y\n$ end\n' != '0wrapout\n0y'

Scenario to just before the error occurs:
Visible terminal (5x10) is like this before resizing (scrolled_by = 0):

$ 4       |
$ wrapcmd |
0wrapout  |
0y        |
          |

Then resized (5x5) to wrap like so, then another prompt is drawn ("$ end", scrolled_by = 2):

$ wra|
pcmd |
0wrap|
out  |
0y   |

With the patch, the AssertionError: '0wrapout\n0y\n$ end\n' != '0wrapout\n0y' indicates that range_line_is_continued in the downwards search returns true for the line of the last prompt ($ end), and continues to the end of the lines, suggesting the line before it "0y" has next_char_was_wrapped = true. At least, that's my assumption.

[kovidgoyal]

It should be easy to verify what is happenning using screen.dump_lines_with_attrs() which marks a line as continued if range_line_is_continued() is true for it.

[rivenirvana]

Thanks for the tip, should've known about screen.dump_lines_with_attrs().
With it, I can confirm that there is indeed something messing up continued attributes, but not when resizing as I initially assumed, but when scrolling via s.scroll() or s.scroll_to_prompt().
To illustrate simply, this is a table indicating which indices (from the test) the continued attribute appears in at different scrolling positions:

scrolled_by	continued idx
0 (correct)	-6,-1,1
1	-6,0,2
2	-6,1,3

The observable pattern suggests the scrolled_by value is affecting some of the lines somehow. I've been checking if it's in screen_pause_rendering() via dirty_scroll(), but no luck yet.

[kovidgoyal]

This should fix the scrolled_by issue: c0f5170