Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
chopptimus opened this issue Jul 22, 2021 · 6 comments · May be fixed by #1499
Open

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

chopptimus opened this issue Jul 22, 2021 · 6 comments · May be fixed by #1499

Comments

@chopptimus
Copy link

chopptimus commented Jul 22, 2021 •
edited
Loading

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
Copy link
Member

tomdl89 commented Jul 22, 2021

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
Copy link
Contributor

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
Copy link
Member

tomdl89 commented Jul 23, 2021

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.

@chopptimus
Copy link
Author

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 added a commit that referenced this issue Jul 23, 2021
@tomdl89
Revert "Scroll half of the visible screen respecting zoom level (#1490)"
3205851 
This reverts commit 070abb1.

As noted in #1497 this introduced bugs which imo are worse than the
bug this commit aims to solve. More work needed.
@tomdl89
Copy link
Member

tomdl89 commented Jul 23, 2021

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
Copy link
Contributor

@tomdl89 Sure, I'll take a look.

countvajhula added a commit to countvajhula/evil that referenced this issue Jul 23, 2021
@countvajhula
Use text scale in calculating visible window height (fix emacs-evil#1497
2f8e3ec 
)
@countvajhula countvajhula linked a pull request Jul 23, 2021 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use text scale in calculating visible window height countvajhula/evil
3 participants
@countvajhula @chopptimus @tomdl89