Allow scrolling past the main cursor in the view mode

[alexherbo2]

https://discuss.kakoune.com/t/view-mode-movement/745/4

[Delapouite]

Strongly related to #2844

[FlyingWombat]

So, do you think the view should push the cursor? Or should the cursor stay put, and have the view snap back to the cursor on a normal key press?

[alexherbo2]

Behave like the scrolling in web browsers, don’t allow interacting with selections in the view mode.

[Anfid]

As far as I understand, currently there are 2 kinds of scrolling. One restores all cursor selections after scrolling (vj, vk), and the other one does not (mouse scroll, <c-d>, <c-u>). In the second case, all selections are always just dropped (even if scrolling does not move main cursor) and the cursor is moved if necessary.

I see this issue fixed in following ways:

1. As @alexherbo2 suggested, allow scrolling past the main cursor and prevent interactions with selections. However, what should happen in this case on cursor movement command after scroll? I also feel like allowing cursor to be out of view will break many existing configurations, but make future ones more flexible.
2. Prevent restoring selections (i.e. drop all selections) only if next scroll command will move the main cursor and make this the "default" kind of scroll. In case users need to scroll till cursor, there are already vt and vb commands.
3. Create custom mappings that mimic the behavior described in second point. Currently it is more hacky, than I want it to be, because there is no direct way of getting current view position. This requires getting it with gtGb, parsing selection to get line numbers and saving it to separate variable. Then in the binding compare current cursor position with view position and work with that. Possibly exporting few extra view variables (like window_top, window_left etc.) would simplify this logic enough for average user to set it up.

I think I could get my hands on either of two last variants, but not confident enough to try implementing the first. Any opinions on this?

[Anfid]

I actually did implement 3rd option locally and scroll command in my config looks like this:

define-command -params 2 scroll %{ execute-keys %sh{
    if [ $1 = "down" ]; then
        if [ "$kak_window_top" = "$kak_cursor_line" ]; then
            echo "<space>;${2}j${2}vj"
        else
            echo ${2}vj
        fi
    elif [ $1 = "up" ]; then
        if [ "$(($kak_window_bottom))" = "$kak_cursor_line" ]; then
            echo "<space>;${2}k${2}vk"
        else
            echo ${2}vk
        fi
    fi
} }

map global normal <a-j> ': scroll down 5<ret>'
map global normal <a-k> ': scroll up 5<ret>'

I added window_top, bottom, left and right builtin variables.

However, I only see this as a temporary solution and think that core scrolling function should be reworked.

[alexherbo2]

@mawww Can you reopen the issue?

It’s too easy to destroy crafted selections with mouse scrolls and clicks (when activating a window, it also sets the selection) or keyboard scrolls (e.g. Page Up and Page Down keys).

You can see how scrolling past the main selection behaves in Dance for example. It works well, as Dance notifies you with hidden selections (see #2727 for a screenshot). Helix also highlights line numbers, so you can see where the main and other selections reside.