Kakoune: Selections are clamped when scrolling slightly

[lenormf]

Steps

• create a multiple selection, centered in the middle of the buffer (need to be able to scroll up/down)
• scroll up or down by one line

Outcome

The selections are clamped, as if space and ; had been hit.

Expected

The multiple selection is left intact, and the view scrolled up/down one line.

[mawww]

I cannot reproduce that here, I selected a few lines in the middle of the displayed buffer, splitted them on line ending and used vj / vk to scroll around a bit. Do you have a more precise reproduction method ?

[TeddyDD]

I can reproduce it with mouse wheel and lastest release (whatever date/number it was). In this case, there's only one selection left

[lenormf]

The mouse wheel is the key.

[daboross]

I can reproduce this using c-d and c-u and when using the mouse wheel. pgup and pgdown also clamp but that's kind of expected.

It does not occur with vj nor vk, those work correctly.

Here's a screen capture showing the issue both with scrolling and c-d/c-u: https://webmshare.com/n5GDy

[mawww]

Yeah, all that is kind-of expected, There is two kinds of scrolling in Kakoune, selection preserving scrolling (vj/vk) which blocks scrolling when the main cursor would become hidden, and regular scrolling (pgup/pgdown/wheel...) which moves the selections out of the way to be able to scroll as requested.

We could introduce a complex system that only touches selections when we absolutely need to, but I doubt it would be that usefull. I find vt vv and vb to work very well if I need to preserve my selection and see more context.

[lenormf]

It's understood why the selections are reset when they hit the borders of the window, but I think users who use their mouse to adjust the view expect the same behavior as a when scrolling a web page.

[mawww]

Scrolling a web page does not guarantee the selection cursor is visible though, would you want this to change in Kakoune as well ?

[lenormf]

It would probably be convenient, but it's not a big deal to me.

[daboross]

I appreciate the current behavior when the cursor is at the edge of the screen. Having it following the screen means I can move immediately after with hjkl without having to click on text first to make sure the scrolling isn't immediately undone.

Still, having the cursor stay the same and exist below or above the screen view could also be good. It is what most graphical editors which don't have good keyboard navigation do.

[FlyingWombat]

Another use case for why one would want to scroll without clamping the selections is when searching and selecting matches. Using %sfoo<ret>, you can search and select matches off the screen, but you can't scroll down to see those selections. It would be helpful to be able to verify that these kinds of selections are correct.

[Screwtapello]

For the %s use-case, you can change which cursor is the primary cursor with ( and ), bringing it into view.