#972572 emacs-gtk: with misc-fixed 13-pixel fonts, unexpected scroll when the cursor is on the last line of the window

Package:
emacs-gtk
Source:
emacs
Description:
GNU Emacs editor (with GTK+ GUI support)
Submitter:
Vincent Lefevre
Date:
2021-02-21 17:36:05 UTC
Severity:
normal
Tags:
#972572#5
Date:
2020-10-20 14:23:56 UTC
From:
To:
Create a file with:

  printf "%d\n" `seq 1000` > file

and open it with "emacs -q" (the issue is not reproducible with -Q).
Go to the end of the file with ESC > then scroll upward with the mouse
wheel (button 4) several times. When the cursor needs repositioning,
this actually scrolls downward, probably because Emacs tries to center
the mouse cursor instead of letting it at the bottom.

No such issue with the other way round, where the cursor remains at
the top.

No such issue with "emacs -Q", where the cursor remains at the bottom.
This should be how Emacs should behave with the site-wide startup file.
#972572#10
Date:
2020-10-20 14:32:02 UTC
From:
To:
Note also that there is no such issue on Debian 10 (buster).
#972572#17
Date:
2020-10-27 01:34:27 UTC
From:
To:
That's strange. I'm on another machine, and I can't reproduce the
bug, and I can't reproduce it either when I connect by SSH to the
machine where it was occurring.

Perhaps that's related to the X server or to the mouse.
#972572#22
Date:
2020-10-28 13:15:15 UTC
From:
To:
Control: retitle -1 emacs-gtk: with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

No, this comes from the font! The problem is reproducible with

  emacs -q -fn -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

but not with

  emacs -q -fn 6x13

or

  emacs -q -fn "DejaVu Sans Mono"

for instance.

Why would the font affect the scrolling behavior???
#972572#29
Date:
2020-10-28 13:25:02 UTC
From:
To:
And with the -fn option, I can reproduce the issue even with -Q:

  emacs -Q -fn -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 file
#972572#34
Date:
2020-10-28 16:43:32 UTC
From:
To:
I have just reported the bug upstream.
#972572#43
Date:
2020-10-30 18:38:24 UTC
From:
To:
according to my tests.

Note: the problem doesn't seem to be reproducible with misc-fixed
fonts that do not have a pixel size equal to 13.
#972572#50
Date:
2020-11-01 00:37:18 UTC
From:
To:
The cause is that with the cairo version (like in Debian),
row->phys_ascent > row->ascent. There are 2 issues:

1. The fact that this condition is true with misc-fixed 13-pixel fonts.

2. The fact that this condition is handled incorrectly by Emacs.
#972572#57
Date:
2020-11-07 11:11:00 UTC
From:
To:
Control: tags -1 fixed-upstream patch
that is expected to be an integer here (this is a bitmap font, thus
with integer parameters), but due to a rounding error in Cairo, one
gets a slightly larger value, so that ceil() gives the next integer:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44284#74

Note that this explains why the issue occurs only with a particular
font size (the rounding error depends on the font size, and the issue
can occur only when this error is positive and large enough).

I've suggested several solutions:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44284#80

In short: Cairo should ideally produce a correctly rounded value,
but guaranteeing that in general may be complex and may yield a
performance drop. Alternatively, assume in Emacs that a value
slightly above the integer is this integer. That's how this has
been patched by Eli Zaretskii:

-      cache->ascent = ceil (- extents.y_bearing);
+      cache->ascent = ceil (- extents.y_bearing - 1.0 / 256);

(see attached patch, which applies to the Debian version too).

Thanks to the above patch, this condition no longer occurs in this
case. I don't know whether there are issues when it occurs in other
cases.