Kakoune: `<pageup>` doesn't scroll all the way up with wrapped lines

[lenormf]

Hi,

When some lines are wrapped in the current buffer and the main selection is somewhere a few views down the top of the buffer, hitting <pageup> repeatedly won't send the selection back to the first line, it will stop a couple lines after (forcing the user to hit gg).

HTH.

[ghost]

Possibly related to this is that I've noticed that vc (center cursor vertically) does not work as expected with wrapped lines: Except at the top of the buffer, the cursor is always repositioned in the lower half of the window, not centrally.

[blastrock]

I have a similar bug, I don't know if it's related, but with wrap enable, I can't use ctrl-u to go up when I want.

Here's a reproduction:

python3 -c 'print(("x" * 120 + "\n") * 100 + ("y" * 30 + "\n") * 10)' > /tmp/k
kak /tmp/k

I'm opening this file in a terminal of size 90x37
Now go to the bottom (gj), and go up from there by pressing multiple times ctrl-u. It will scroll a few lines up and then get stuck at the first wrapped line.

[lenormf]

Any idea how easy it would be to fix this?

[mawww]

This is hard to fix, and the more I look at the wrap highlighter, the more I think trying to cram all that (wrap, line numbers, flag lines...) in a single "highlighter" abstraction is failing. But I dont see any satisfying alternatives.

[ManDay]

For information, quote mawww from IRC:

The problem with wrap highlighter is that for performance reason, and by
design, we only wrap what is visible, which means any buffer moving commands cannot
rely on the wrapping as we might have selections that are not visible. Additionally, we
do not have easy access to the informations about how lines are going to wrap outside
of the wrap highlighter itself, so view commands, PgUp/PgDown have a
hard time knowing how lines are actually going to be displayed and hence how to center
a line in the presence of wrapped lines.

[ManDay]

I think the least intrusive solution to achieve perfectly natural behaviour consists of two parts (the first of which, I presume, is already available):

• Position the view based upon line number and character index. This would be strictly necessary to allow for a PgUp or PgDn operation with wrapped lines. Consider, for example the situation where even scrolling up by even a whole, single line results in more than a whole page of scrolling.

• Symmetrize the view code. I don't know how well this integrates with more basic things like the fact that files are often considered as a directed stream. Semantically, however, if the position can be anchored by the bottom right corner (line, character index), the need for a "convergent feedback"/trial and error positioning during a PgUp operation disappears, as the necessary a-priori information becomes available.

Without this symmetrization, an iterative solution which involves the core logic is inherently mandatory, if no a-priori information is available. I see two, less satisfactory, alternatives to the symmetrization w.r.t. the problems particular to scrolling up which do not require a feedback loop:

• Use a-priori information pertaining to soft-wrapping, i.e. define PgUp natively such that it anchors the view by line and character index based upon the current anchor and counting backwards character. Basically, this partly incorporates wrap-highlighter specific features into the core (bad) and would thus not work for arbitrary highlighters, which may transform the output in a different way.
• Re-define the meaning of view commands such as PgUp to be less natural, but consistent and still satisfactory to the user, such that at least the obvious mistake of PgUp not reaching to the top of the page can be prevented. In that regard, I can only imagine that moving a fixed amount of lines, irrespective of the wrap-highlighter, is sensible. With (soft-)wrapping enabled, the user loses a few lines, but the typical intent of PgUp being "move up fast" is still kept, in certain way.

[eikenb]

Just hit this one. Noticed that scroll wheel worked fine going down but would hang as soon as the cursor hits the bottom of the page going up.

Any suggested workarounds for this? My best idea is to have wrap off by default with a key map to toggle it on/off when you need it..

define-command wrap-toggle %{
    try %{
        addhl global/wrap wrap # line wrapping on
    } catch %{
        rmhl global/wrap # line wrapping off
    }
}

map global normal <c-w> ':wrap-toggle<ret>'

[lenormf]

I generally hit ge or gg when the cursor won't go further up/down.

[eikenb]

Another purely physical workaround is to just click as you spin. By resetting the cursor into the middle of the window you keep the scroll working.

[Jackojc]

Any updates on addressing this issue?

[AJChapman]

I have a similar issue which may have the same cause, so I'll describe it here.

The issue is that scrolling by page (either by using <c-f>/<c-b> or <pagedown>/<pageup>) with line wrapping enabled scrolls by more lines than are visible. For example, if my view spans from line 1 to 48, with many lines wrapping (30 in this case), and I scroll one page down, my view now spans from line 77 to 132, but the new span should have started at line 49! Note that 49 + 30 = 79 (The out-by-2 may be explained by the last line of the original view also spanning several lines, three of which are visible. Maybe this line isn't counted in the scroll).

Just on the severity of this bug: it can cause serious human errors if e.g. I'm trying to read a file, and scrolling through it by page, then I will miss large amounts of the content! I fell victim to this on a number of occasions before I realised that I couldn't trust the scrolling. But it still gets me.

Reproduced in Kakoune v2020.01.16.

[AJChapman]

Yet another incarnation of what may be the same issue: If the last line of a file wraps, then gj does not show the very end of the file. E.g. if the last line of the file is line 1271, and I go there with gj, then I can see the beginning of line 1271, but I can't see that it spans two lines until I subequently go to the end of the line with gl. Now the view scrolls to show two lines with number 1271 and I can see the end of the file.

[caksoylar]

FWIW I am also hitting this issue with kakoune-smooth-scroll, where I cannot use vj/vk to emulate native <c-d>/<c-f>/<c-u>/<c-b> since it gets stuck at wrapped lines. I ended up with a solution that also moves the cursor like vjj/vkk, but that's not how above maps work natively.

[losnappas]

This really is a rather severe issue. Scrolling up using the mouse wheel is borderline impossible; it's constantly getting stuck. Real annoying.

I wish the cursor could drop out of view, so I could more easily look around the surrounding code without messing up my position.

[GavinSmith0123]

I found the code that was blocking the scrolling and disabled it:

--- a/src/highlighters.cc
+++ b/src/highlighters.cc
@@ -806,23 +806,25 @@ struct WrapHighlighter : Highlighter
                 }
                 kak_assert(setup.cursor_pos.column >= 0 and setup.cursor_pos.column < setup.window_range.column);
             }
             const auto wrap_count = line_wrap_count(buf_line, prefix_len);
             win_line += wrap_count + 1;

+#if 0
             // scroll window to keep cursor visible, and update range as lines gets removed
             while (buf_line >= cursor.line and setup.window_pos.line < cursor.line and
                    setup.cursor_pos.line + setup.scroll_offset.line >= win_height)
             {
                 auto remove_count = 1 + line_wrap_count(setup.window_pos.line, indent);
                 ++setup.window_pos.line;
                 --setup.window_range.line;
                 setup.cursor_pos.line -= std::min(win_height, remove_count);
                 win_line -= remove_count;
                 kak_assert(setup.cursor_pos.line >= 0);
             }
+#endif
         }
     }

     void fill_unique_ids(Vector<StringView>& unique_ids) const override
     {
         unique_ids.push_back(ms_id);

With this, you can scroll up and down freely. It's not perfect, as the cursor can disappear off the bottom of the window when you are scrolling up, but this is no problem at all if you are using a mouse, as you can simply click the window to get the cursor back again. For my usage, broken scrolling with the mouse scrollwheel is a very severe bug.