evil-scroll-up and evil-scroll-down do not work correctly when end of buffer is visible

[hugojry]

Issue type

Bug report

Environment

Emacs version: 28.0.50
Operating System: Ubuntu 20.4
Evil version: 1.14.0
Evil installation type: MELPA, MELPA stable, Quelpa, El-Get, manual -->
Graphical/Terminal: Graphical
Tested in a make emacs session (see CONTRIBUTING.md): Yes

Reproduction steps

• Start Emacs with make emacs
• Open file with enough lines to fill a whole window
• Using C-e, scroll down so only the last line of the buffer is visible
• M-x evil-scroll-up

Expected behavior

The window should be half filled with lines from the buffer.

Actual behavior

The window doesn't scroll at all.

Further notes

This is because evil-scroll-up (and evil-scroll-down) use evil-visible-window-height which reports incorrect values for window height when the window is positioned over the end of the buffer.

[tomdl89]

My initial thought was that we could travel up to line 0 and do the calcs, in a save excursion, but it seems all of the functions that detect the top/bottom of the window want an actual redisplay before acknowledging any new position. So the best I could come up with is guessing the window height by looking at text-scale-mode-step and text-scale-mode-amount:

(let ((current-scale (expt text-scale-mode-step text-scale-mode-amount)))
  (/ (window-body-height) current-scale))

This is 3 or 4 lines too high for the zoom levels I tested, and I'm not sure what causes this difference. We could try just bunging in a magic number:

(let ((current-scale (expt text-scale-mode-step text-scale-mode-amount)))
    (- (floor (/ (window-body-height) current-scale)) 3))

but I'd rather find a proper way.
Any ideas @countvajhula ?

[countvajhula]

I'm not sure what text-scale-mode-step and text-scale-mode-amount do, but for me, the former value doesn't change no matter what zoom level I use. The latter changes by a set increment of 1 each time rather than by a scale factor, so that makes me think that these variables don't actually track anything concrete as far as the real visible scale goes, maybe just a zoom "index" of some kind, but, I'd need to take a closer look.

Also, I noticed that in Vim, C-d and C-u scroll exactly so that the middle line is at the bottom/top of the screen (at any zoom level), whereas with evil-window-visible-height it's scrolling a little short of that. Modifying the value computation to:
(setq count (1+ (/ (evil-window-visible-height) 2))) fixes the issue and brings it to parity with Vim as far as non-edgecase behavior goes, and for the end-of-buffer case it at least scrolls the window by a line, so that it doesn't get stuck there as described in this issue. But obviously that's still not quite right (and Vim does the right thing here).

[tomdl89]

Well spotted @countvajhula - we should adjust that. The text-scale-mode-step and text-scale-mode-amount are what text-scale-adjust use to calculate the new height of the default face, so I'm thinking they could be used (maybe only if (pos-visible-in-window-p (point-max)) is true ?) to guess the current correct value returned by evil-window-visible-height. Needs a bit more thought.

[hugojry]

Another problem I've just noticed: a window filled with a single line that takes up the majority of the window due to truncate-lines is not scrolled by evil-scroll-up or evil-scroll-down. Vim scrolls by a single line in this scenario.

[tomdl89]

I've reverted the commit which caused these bugs. Sorry for the inconvenience @chopptimus.
@countvajhula feel free to take a look at a solution if you can. If not, I will try to find the time, although maybe not soon.

[countvajhula]

@tomdl89 Sure, I'll take a look.