Make scroll behaviour more similar to vim

[tremby]

Closes https://github.com/ambientsound/pms/issues/94

Behaviour is not identical to vim, but is much closer.

Vim has weird edge cases. Examples with scrolloff=0, a buffer with many lines, and a window 10 lines tall:

• Cursor at line 1. Lines 1 to 10 are visible. ^F. Now lines 9 to 18 are visible and the cursor is at 9. ^B. Now lines 1 to 10 are visible again, but the cursor has moved down one line to 10.

• Cursor at line 1. Lines 1 to 10 are visible. ^F. Now lines 9 to 18 are visible and the cursor is at 9. ^E. Now lines 10 to 19 are visible and the cursor is at 10. ^B. Now lines 1 to 10 are visible.

• Cursor at line 1. Lines 1 to 10 are visible. ^F. Now lines 9 to 18 are visible and the cursor is at 9. ^E^E. Now lines 11 to 20 are visible and the cursor is at 11. ^B. Now lines 3 to 12 are visible.

• Cursor at line 1. ^E. Lines 2 to 10 are visible and the cursor is at 2. ^B. Lines 1 to 10 are visible but cursor is at 3.

• Cursor at line 1. ^E^E. Lines 3 to 11 are visible and the cursor is at 3. ^B. Lines 1 to 10 are visible but cursor is at 4.

I haven't tried to recreate all of this, since I'm not convinced it's actually intentional behaviour.

The behaviour I've ended up with, instead, is this:

• Page up and down commands scroll the whole viewport but leave the cursor alone as much as possible.

• The viewport is scrolled by a full page minus two rows in most cases. If the viewport is 4 lines high, it scrolls 3 lines. If the viewport is 3 or fewer lines high, it scrolls a full page. This is as vim.

• Since if the window is five or more rows there are two lines of context, and since we leave the cursor on the same song if possible, ^F^F^B ends up with the cursor one row from the bottom, and ^B^B^F ends up with the cursor one row from the top. This is not like vim but I think it's probably the intended behaviour (at least it makes sense to me).

• The half page commands move both the viewport and the cursor by half a page. These are independent, so if the viewport can only scroll two more rows, the cursor will still move further, and vice versa. This works just like vim in all the comparisons I've made, other than near the very bottom (since vim allows scrolling to continue and shows ~ rows).

I've moved the page up/down and half page up/down commands to the viewport namespace, since I think they make more sense here.

[codecov-io]

Codecov Report

Merging #96 into master will decrease coverage by 0.36%. The diff coverage is 32.43%.

@@            Coverage Diff             @@
##           master      #96      +/-   ##
==========================================
- Coverage   54.01%   53.65%   -0.37%     
==========================================
  Files          51       51              
  Lines        1779     1791      +12     
==========================================
  Hits          961      961              
- Misses        796      807      +11     
- Partials       22       23       +1

Impacted Files	Coverage Δ
commands/cursor.go	62.5% <ø> (+1.38%)	:arrow_up:
options/defaults.go	0% <ø> (ø)	:arrow_up:
commands/viewport.go	56.25% <32.43%> (-23.75%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update c4e1a15...4917b63. Read the comment docs.

[tremby]

Will do, and then will rebase the other branch.

[kimtore]

Thanks. There is also a bug in center mode: when using page up near the top, or page down near the bottom, the cursor is not moved to the start or end of the list.

[tremby]

That's not a bug in my opinion! That's how it works in vim.

[kimtore]

My Vim only "blocks" on page up. It scrolls down to the very bottom, marking the last line and leaving only that line visible. So this behavior is dubious. I see your point on separating viewport and cursor, but in my opinion it will be more user-friendly to have the cursor move to the edge at the same time.

[tremby]

That behaviour at the bottom is because vim lets you keep scrolling at the bottom, showing you ~ rows. PMS doesn't do that (though it could...)

I don't agree regarding page up moving the cursor to the top. Page up moves the viewport a page up, and it's already at the top, so it's right that it shouldn't do anything. There are plenty of other ways to get the cursor to the top: gg, H, ^U. I'm back to banging the vim drum of course, but I think staying close to what vim does is best here.

Would you be on the same page as me if we implemented the ~ rows at the bottom, resulting in ^F getting you eventually to the very last song? Vim also rings the bell if you try to ^B when already at the top. We could do that too?

[kimtore]

With this change, PgUp will move the viewport instead of the cursor. Semantically, it is correct not to move the cursor to the top. That said, having to switch from PgUp to gg requires moving the fingers (context switching), so the correctness might come at the expense of user-friendlyness.

I don't think implementing ~ lines is useful, as the primitive in PMS is the song and not the character.

Given as Vim-like is a key selling point for users, it's important to make PMS look and feel right for Vim users. Thus, I'm going to accept your pull request. If the cursor functionality becomes important enough, it can be re-implemented as cursor [...] commands.

[tremby]

That said, having to switch from PgUp to gg requires moving the fingers (context switching)

Not if using ^F and ^B, which I would have thought most vim users would rather than pgup/pgdn keys. If using pgup/pgdn, there are also the home and end keys anyway.

I don't think implementing ~ lines is useful, as the primitive in PMS is the song and not the character.

I'm not sure I fully understand your line of thinking here. Could you elaborate?

If the cursor functionality becomes important enough, it can be re-implemented as cursor [...] commands.

Yes, no reason we couldn't add :cursor pageup et al back in, with their old behaviour, but I just question how useful they'd be. The weirdness of only scrolling a single row in some cases puts me off of it.

Thanks for merging!

[kimtore]

I don't think implementing ~ lines is useful, as the primitive in PMS is the song and not the character.

I'm not sure I fully understand your line of thinking here. Could you elaborate?

What I mean is that ~ markers are useful in Vim because one can scroll further down than the file, enter input mode, and start adding text. This mode of playlist manipulation wouldn't really be practical in PMS.

Thanks for merging!

Thanks for the pull request!

[tremby]

Oh, I see now. So you mean scroll down so lots of ~ are in view and then add many lines of text at once without anything scrolling.