bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

Under Debian/unstable, create a file with

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

then open it using GNU Emacs 27.1 with

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

Go to the end of the file with ESC > then scroll upward with the
mouse wheel (button 4) several times (but slowly). 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.

Note: I have old GNU Emacs 27.0.91 snapshot versions still installed,
one compiled on 2020-05-14 without cairo, and I cannot reproduce the
bug with it (the cursor remains at the bottom), and one compiled on
2020-05-15 with Cairo (--with-cairo), and the bug occurs with it.


In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
 of 2020-10-24, modified by Debian built on x86-conova-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Debian GNU/Linux bullseye/sid

Recent messages:
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /etc/emacs/site-start.d/50reposurgeon.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done
Loading /etc/emacs/site-start.d/50w3m-el.el (source)...done
Loading /etc/emacs/site-start.d/50why3.el (source)...done
Loading /home/vlefevre/share/emacs/site-lisp/mutteditor.el (source)...done
Loading time...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
<mouse-4> is undefined [3 times]

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --enable-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --build
 x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
 --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-cairo
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/emacs-bB10hX/emacs-27.1+1=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall'
 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD
JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: C.UTF-8
  value of $LC_TIME: en_DK.utf8
  value of $LANG: POSIX
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  display-time-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/llvm-10/llvm-mode hides /usr/share/emacs/site-lisp/llvm-3.6/llvm-mode
/usr/share/emacs/site-lisp/llvm-10/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-3.6/tablegen-mode
/usr/share/emacs/site-lisp/llvm-10/emacs hides /usr/share/emacs/site-lisp/llvm-3.6/emacs
/usr/share/emacs/site-lisp/llvm-10/llvm-mode hides /usr/share/emacs/site-lisp/llvm-3.7/llvm-mode
/usr/share/emacs/site-lisp/llvm-10/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-3.7/tablegen-mode
/usr/share/emacs/site-lisp/llvm-10/emacs hides /usr/share/emacs/site-lisp/llvm-3.7/emacs
/usr/share/emacs/site-lisp/llvm-10/llvm-mode hides /usr/share/emacs/site-lisp/llvm-6.0/llvm-mode
/usr/share/emacs/site-lisp/llvm-10/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-6.0/tablegen-mode
/usr/share/emacs/site-lisp/llvm-10/emacs hides /usr/share/emacs/site-lisp/llvm-6.0/emacs
/usr/share/emacs/site-lisp/llvm-10/llvm-mode hides /usr/share/emacs/site-lisp/llvm-7/llvm-mode
/usr/share/emacs/site-lisp/llvm-10/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-7/tablegen-mode
/usr/share/emacs/site-lisp/llvm-10/emacs hides /usr/share/emacs/site-lisp/llvm-7/emacs
/usr/share/emacs/site-lisp/llvm-10/llvm-mode hides /usr/share/emacs/site-lisp/llvm-8/llvm-mode
/usr/share/emacs/site-lisp/llvm-10/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-8/tablegen-mode
/usr/share/emacs/site-lisp/llvm-10/emacs hides /usr/share/emacs/site-lisp/llvm-8/emacs
/usr/share/emacs/site-lisp/llvm-10/llvm-mode hides /usr/share/emacs/site-lisp/llvm-9/llvm-mode
/usr/share/emacs/site-lisp/llvm-10/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-9/tablegen-mode
/usr/share/emacs/site-lisp/llvm-10/emacs hides /usr/share/emacs/site-lisp/llvm-9/emacs
/usr/share/emacs/site-lisp/flim/md4 hides /usr/share/emacs/27.1/lisp/md4
/usr/share/emacs/site-lisp/flim/hex-util hides /usr/share/emacs/27.1/lisp/hex-util
/usr/share/emacs/site-lisp/flim/sasl-cram hides /usr/share/emacs/27.1/lisp/net/sasl-cram
/usr/share/emacs/site-lisp/flim/hmac-md5 hides /usr/share/emacs/27.1/lisp/net/hmac-md5
/usr/share/emacs/site-lisp/flim/hmac-def hides /usr/share/emacs/27.1/lisp/net/hmac-def
/usr/share/emacs/site-lisp/flim/sasl-digest hides /usr/share/emacs/27.1/lisp/net/sasl-digest
/usr/share/emacs/site-lisp/flim/sasl hides /usr/share/emacs/27.1/lisp/net/sasl
/usr/share/emacs/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/27.1/lisp/net/sasl-ntlm
/usr/share/emacs/site-lisp/flim/ntlm hides /usr/share/emacs/27.1/lisp/net/ntlm
/usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/27.1/lisp/language/thai-word

Features:
(shadow sort mail-extr warnings emacsbug message rmc puny dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date subr-x seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time cus-start cus-load paren cc-styles
cc-align cc-engine cc-vars cc-defs edmacro kmacro cl-loaddefs cl-lib
w3m-load tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 70231 7098)
 (symbols 48 9062 1)
 (strings 32 22942 1331)
 (string-bytes 1 738076)
 (vectors 16 10797)
 (vector-slots 8 143077 9264)
 (floats 8 26 24)
 (intervals 56 252 0)
 (buffers 1000 13))

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

I forgot to say that the chosen font matters, which looks surprising.
For instance, the bug doesn't occur with 6x13, nor with "DejaVu Sans Mono".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> From: Vincent Lefevre <vincent@vinc17.net>
> Date: Wed, 28 Oct 2020 17:36:37 +0100
> 
> 
> Under Debian/unstable, create a file with
> 
>   printf "%d\n" `seq 1000` > file
> 
> then open it using GNU Emacs 27.1 with
> 
>   emacs -Q -fn misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 file
> 
> Go to the end of the file with ESC > then scroll upward with the
> mouse wheel (button 4) several times (but slowly). 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.

Please try the latest emacs-27 branch or the master, it's possible
that this is already fixed there.  (I couldn't verify myself if this
is fixed as I cannot reproduce the original problem to begin with.)

Thanks.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-10-28 18:53:37 +0200, Eli Zaretskii wrote:
> Please try the latest emacs-27 branch or the master, it's possible
> that this is already fixed there.  (I couldn't verify myself if this
> is fixed as I cannot reproduce the original problem to begin with.)

Still the same problem with the latest emacs-27 branch
(da6234e2dfd8c345bad1ff3075033b282b64f958).

GNU Emacs 27.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0) of 2020-10-30

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Fri, 30 Oct 2020 11:52:28 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> On 2020-10-28 18:53:37 +0200, Eli Zaretskii wrote:
> > Please try the latest emacs-27 branch or the master, it's possible
> > that this is already fixed there.  (I couldn't verify myself if this
> > is fixed as I cannot reproduce the original problem to begin with.)
> 
> Still the same problem with the latest emacs-27 branch
> (da6234e2dfd8c345bad1ff3075033b282b64f958).
> 
> GNU Emacs 27.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0) of 2020-10-30

Thanks.  This means that I will need a reproduction recipe with some
less Unix-specific font, because I tried a lot of different font sizes
and couldn't reproduce the problem, at least not in "emacs -Q".

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-10-30 13:31:54 +0200, Eli Zaretskii wrote:
> Thanks.  This means that I will need a reproduction recipe with some
> less Unix-specific font, because I tried a lot of different font sizes
> and couldn't reproduce the problem, at least not in "emacs -Q".

Note that here the bug is reproducible with

  -misc-fixed-bold-r-normal--13-100-100-100-c-70-iso8859-1
  -misc-fixed-bold-r-normal--13-100-100-100-c-80-iso8859-1
  -misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1
  -misc-fixed-medium-r-normal--13-100-100-100-c-80-iso8859-1
  -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1
  -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
  -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

but not with

  -misc-fixed-medium-r-normal--0-0-75-75-c-0-iso10646-1
  -misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1
  -misc-fixed-medium-r-normal--9-90-75-75-c-60-iso10646-1
  -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso10646-1
  -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1
  -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1
  -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso10646-1
  -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso10646-1

So it seems to be the "13" that is the problem.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Fri, 30 Oct 2020 14:33:36 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> On 2020-10-30 13:31:54 +0200, Eli Zaretskii wrote:
> > Thanks.  This means that I will need a reproduction recipe with some
> > less Unix-specific font, because I tried a lot of different font sizes
> > and couldn't reproduce the problem, at least not in "emacs -Q".
> 
> Note that here the bug is reproducible with
> 
>   -misc-fixed-bold-r-normal--13-100-100-100-c-70-iso8859-1
>   -misc-fixed-bold-r-normal--13-100-100-100-c-80-iso8859-1
>   -misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1
>   -misc-fixed-medium-r-normal--13-100-100-100-c-80-iso8859-1
>   -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1
>   -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
>   -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
> 
> but not with
> 
>   -misc-fixed-medium-r-normal--0-0-75-75-c-0-iso10646-1
>   -misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1
>   -misc-fixed-medium-r-normal--9-90-75-75-c-60-iso10646-1
>   -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso10646-1
>   -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1
>   -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1
>   -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso10646-1
>   -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso10646-1
> 
> So it seems to be the "13" that is the problem.

Yes, but I don't have access to a system with misc-fixed font, and the
replacement I have here refuses to reproduce the problem with many
sizes I tried.  So I need help in reproducing the issue, before I
could debug it.

Thanks.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-10-30 15:37:10 +0200, Eli Zaretskii wrote:
> Yes, but I don't have access to a system with misc-fixed font, and the
> replacement I have here refuses to reproduce the problem with many
> sizes I tried.  So I need help in reproducing the issue, before I
> could debug it.

Note: I've just noticed an editing issue, so that the font name I gave
in the bug report was wrong (I suspect that when I fixed the Emacs
word wrapping of the copy-pasted command, I inadvertently removed the
initial dash of the font name). It should be:

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

Sorry about that.

I've also tried the master branch, and it is also buggy.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

I've found the cause of this issue: with the culprit font, it is
not always possible to put the text cursor on the last line in
the window, either with a mouse click or with the down arrow:
Emacs scrolls the text so that the cursor is at the center of
the window. Why/when this occurs remains to be determined (is
there some rounding involved?).

When the bug does not occur with the mouse wheel, the cursor is
put on the last line. But with the culprit font, I suppose that
the above issue causes another scroll in the opposite direction,
hence the observed behavior.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-10-30 21:34:53 +0100, Vincent Lefevre wrote:
> I've found the cause of this issue: with the culprit font, it is
> not always possible to put the text cursor on the last line in
> the window, either with a mouse click or with the down arrow:
> Emacs scrolls the text so that the cursor is at the center of
> the window. Why/when this occurs remains to be determined (is
> there some rounding involved?).

This is contextual. For instance, with

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

I have a window with 34 lines:

1
2
3
.
.
.
33
34

If I move the cursor downward with the down arrow, I can reach
line 33. At line 34 (last line of the window), Emacs scrolls to
have:

17
18
19
.
.
.
49
50

with the cursor on line 34. Then, with the down arrow, I can put the
cursor on line 50, which remains the last line of the window. With
the up arrow, I put the cursor on line 40. With the mouse wheel, I
scroll downward (one time), then upward. I still have lines 17 to 50
with the cursor on line 40. With the down arrow, I can reach line 49,
but at line 50, Emacs scrolls to have lines 33 to 66, while before,
the cursor could be on line 50 as the last line of the window.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Fri, 30 Oct 2020 21:57:02 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> This is contextual. For instance, with
> 
>   emacs -Q -fn -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 file
> 
> I have a window with 34 lines:
> 
> 1
> 2
> 3
> .
> .
> .
> 33
> 34
> 
> If I move the cursor downward with the down arrow, I can reach
> line 33. At line 34 (last line of the window), Emacs scrolls to
> have:
> 
> 17
> 18
> 19
> .
> .
> .
> 49
> 50
> 
> with the cursor on line 34. Then, with the down arrow, I can put the
> cursor on line 50, which remains the last line of the window. With
> the up arrow, I put the cursor on line 40. With the mouse wheel, I
> scroll downward (one time), then upward. I still have lines 17 to 50
> with the cursor on line 40. With the down arrow, I can reach line 49,
> but at line 50, Emacs scrolls to have lines 33 to 66, while before,
> the cursor could be on line 50 as the last line of the window.

Like I said, there's some factor at work here that needs to be
identified.  Which is why I need a reproduction recipe.

Alternatively, someone else who can reproduce this are welcome to
debug this and propose analysis and/or fix.

Thanks.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-10-30 23:09:00 +0200, Eli Zaretskii wrote:
> Alternatively, someone else who can reproduce this are welcome to
> debug this and propose analysis and/or fix.

Perhaps you could give some indication.

FYI, with the culprit font, (move-to-window-line -1) goes to line 34
(the last line in the window), and recenters the cursor.

The move-to-window-line documentation says "-1 meaning the last fully
visible display line of the window". So line 34 would be fully visible,
so that I don't see why the cursor is recentered.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

What happens is the following. In xdisp.c, fucntion redisplay_window:

  /* Handle case where text has not changed, only point, and it has
     not moved off the frame, and we are not retrying after hscroll.
     (current_matrix_up_to_date_p is true when retrying.)  */
  if (current_matrix_up_to_date_p
      && (rc = try_cursor_movement (window, startp, &temp_scroll_step),
	  rc != CURSOR_MOVEMENT_CANNOT_BE_USED))

rc is normally 0, but when the last line is reached, rc = 2
(CURSOR_MOVEMENT_MUST_SCROLL).

So I assume that the bug occurs somewhere in try_cursor_movement.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-10-31 01:46:17 +0100, Vincent Lefevre wrote:
> So I assume that the bug occurs somewhere in try_cursor_movement.

In try_cursor_movement, one has:

	      if (MATRIX_ROW_BOTTOM_Y (row) > last_y
		  || PT > MATRIX_ROW_END_CHARPOS (row)
		  /* Line is completely visible last line in window
		     and PT is to be set in the next line.  */
		  || (MATRIX_ROW_BOTTOM_Y (row) == last_y
		      && PT == MATRIX_ROW_END_CHARPOS (row)
		      && !row->ends_at_zv_p
		      && !MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row)))

With the culprit font, MATRIX_ROW_BOTTOM_Y (row) > last_y becomes 1
when the cursor reaches the last line. With a working font, the value
is still 0.

More precisely, with size 13, MATRIX_ROW_BOTTOM_Y (row) and last_y are:

27 442
40 442
53 442
...
417 442
430 442
443 442  <-- line 34 (last visible line)

and with size 14:

28 476
42 476
56 476
...
448 476
462 476
476 476  <-- line 34 (last visible line)

The issue with size 13 is that MATRIX_ROW_BOTTOM_Y (row) is 13*n+1
instead of 13*n.

That's all for today.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sat, 31 Oct 2020 02:13:50 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> In try_cursor_movement, one has:
> 
> 	      if (MATRIX_ROW_BOTTOM_Y (row) > last_y
> 		  || PT > MATRIX_ROW_END_CHARPOS (row)
> 		  /* Line is completely visible last line in window
> 		     and PT is to be set in the next line.  */
> 		  || (MATRIX_ROW_BOTTOM_Y (row) == last_y
> 		      && PT == MATRIX_ROW_END_CHARPOS (row)
> 		      && !row->ends_at_zv_p
> 		      && !MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row)))
> 
> With the culprit font, MATRIX_ROW_BOTTOM_Y (row) > last_y becomes 1
> when the cursor reaches the last line. With a working font, the value
> is still 0.
> 
> More precisely, with size 13, MATRIX_ROW_BOTTOM_Y (row) and last_y are:
> 
> 27 442
> 40 442
> 53 442
> ...
> 417 442
> 430 442
> 443 442  <-- line 34 (last visible line)
> 
> and with size 14:
> 
> 28 476
> 42 476
> 56 476
> ...
> 448 476
> 462 476
> 476 476  <-- line 34 (last visible line)
> 
> The issue with size 13 is that MATRIX_ROW_BOTTOM_Y (row) is 13*n+1
> instead of 13*n.

Thanks.

What you describe sounds normal to me: this code is designed to detect
these situations.  So I see no bug here, at least not yet.

I think the issue might be elsewhere: in the code that decides to
scroll such that this particular screen line ends up being the last
one, and/or that point should be on this last line.  If this happens,
we will always recenter or move point off that screen line.  So the
right place to look could be in the scrolling code, probably in
window_scroll_pixel_based.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-10-31 09:38:37 +0200, Eli Zaretskii wrote:
> I think the issue might be elsewhere: in the code that decides to
> scroll such that this particular screen line ends up being the last
> one, and/or that point should be on this last line.  If this happens,
> we will always recenter or move point off that screen line.  So the
> right place to look could be in the scrolling code, probably in
> window_scroll_pixel_based.

window_scroll_pixel_based is not called at all, neither window_scroll
is.

What is wrong seems to be the initial position of the text in the
window. Indeed, with xmag (magnifier), I can see that the glyphs
are shifted one line downward. Now, I don't know where to look at.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-10-31 23:43:24 +0100, Vincent Lefevre wrote:
> What is wrong seems to be the initial position of the text in the
> window. Indeed, with xmag (magnifier), I can see that the glyphs
> are shifted one line downward. Now, I don't know where to look at.

The issue is in xdisp.c, function compute_line_metrics.

With size 14, one gets row->height = 14 and everything is fine.

With size 13, one gets row->height = 13 initially, but one enters
the following condition:

      /* If first line's physical ascent is larger than its logical
         ascent, use the physical ascent, and make the row taller.
         This makes accented characters fully visible.  */
      if (row == MATRIX_FIRST_TEXT_ROW (it->w->desired_matrix)
	  && row->phys_ascent > row->ascent)
	{
	  row->height += row->phys_ascent - row->ascent;
	  row->ascent = row->phys_ascent;
	}

where row->height is increased to 14, hence the issue with the first
line. One successively gets

  it->current_y = 0
  it->current_y = 14
  it->current_y = 27

adding 13 each time for the following lines.

With size 14:
row->phys_ascent = 12
row->ascent = 12

With size 13:
row->phys_ascent = 12
row->ascent = 11

I don't know where phys_ascent comes from, but it does not seem to be
in the font description. Anyway, this case is not handled correctly
by Emacs.

Note also that when building without cairo (--without-cairo), I get
with size 13:

row->phys_ascent = 11
row->ascent = 11

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-11-01 01:24:30 +0100, Vincent Lefevre wrote:
[...]
> where row->height is increased to 14, hence the issue with the first
> line. One successively gets
> 
>   it->current_y = 0
>   it->current_y = 14
>   it->current_y = 27
> 
> adding 13 each time for the following lines.

About this, this is in function display_line

  it->current_y += row->height;

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sun, 1 Nov 2020 01:28:03 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> On 2020-11-01 01:24:30 +0100, Vincent Lefevre wrote:
> [...]
> > where row->height is increased to 14, hence the issue with the first
> > line. One successively gets
> > 
> >   it->current_y = 0
> >   it->current_y = 14
> >   it->current_y = 27
> > 
> > adding 13 each time for the following lines.
> 
> About this, this is in function display_line
> 
>   it->current_y += row->height;

Yes, this is how the display engine tracks the Y coordinate of the
screen line it is laying out.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sun, 1 Nov 2020 01:24:30 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> The issue is in xdisp.c, function compute_line_metrics.
> 
> With size 14, one gets row->height = 14 and everything is fine.
> 
> With size 13, one gets row->height = 13 initially, but one enters
> the following condition:
> 
>       /* If first line's physical ascent is larger than its logical
>          ascent, use the physical ascent, and make the row taller.
>          This makes accented characters fully visible.  */
>       if (row == MATRIX_FIRST_TEXT_ROW (it->w->desired_matrix)
> 	  && row->phys_ascent > row->ascent)
> 	{
> 	  row->height += row->phys_ascent - row->ascent;
> 	  row->ascent = row->phys_ascent;
> 	}
> 
> where row->height is increased to 14, hence the issue with the first
> line. One successively gets
> 
>   it->current_y = 0
>   it->current_y = 14
>   it->current_y = 27
> 
> adding 13 each time for the following lines.

Thanks, this makes sense.  But the reason for this is still TBD.

> With size 14:
> row->phys_ascent = 12
> row->ascent = 12
> 
> With size 13:
> row->phys_ascent = 12
> row->ascent = 11
> 
> I don't know where phys_ascent comes from, but it does not seem to be
> in the font description.

It does come from the font data, or at least it should.  See below.

> Anyway, this case is not handled correctly by Emacs.

I think the jury is still out on this issue.

> Note also that when building without cairo (--without-cairo), I get
> with size 13:
> 
> row->phys_ascent = 11
> row->ascent = 11

Interesting.  Once you understand where did the value 12 come from,
perhaps you could see how things are different in a non-Cairo build.

Let me describe how row->phys_ascent is computed, so that you could
take a closer look.

In general, both the row->ascent and row->phys_ascent values are
computed from the metrics of the character glyphs of the screen line.
The difference between them is that the former is affected by various
features such as the line-spacing and text properties that modify the
height of the text, whereas the latter keeps the value gleaned from
the character metrics.

The row->ascent and row->phys_ascent are assigned by display_line,
using the maximum values of ascent and phys_ascent of all the glyphs
laid out on the screen line.  These latter values are tracked by
it->max_ascent and it->max_phys_ascent.  For each character
display_line examines, it calls gui_produce_glyphs (via the macro
PRODUCE_GLYPHS), and there we have this fragment:

	  if (get_char_glyph_code (it->char_to_display, font, &char2b))
	    {
	      pcm = get_per_char_metric (font, &char2b);
	      if (pcm->width == 0
		  && pcm->rbearing == 0 && pcm->lbearing == 0)
		pcm = NULL;
	    }

	  if (pcm)
	    {
	      it->phys_ascent = pcm->ascent + boff;
	      it->phys_descent = pcm->descent - boff;
	      it->pixel_width = pcm->width;

This is where these values start: from the per-character metrics we
get from the font.  Near the end of gui_produce_glyphs, we have this:

  it->max_ascent = max (it->max_ascent, it->ascent);
  it->max_descent = max (it->max_descent, it->descent);
  it->max_phys_ascent = max (it->max_phys_ascent, it->phys_ascent);
  it->max_phys_descent = max (it->max_phys_descent, it->phys_descent);

This accumulates the maximum values of all the glyphs.  Back in
display_line we have, a little ways after the call to PRODUCE_GLYPHS:

	  row->ascent = max (row->ascent, it->max_ascent);
	  row->height = max (row->height, it->max_ascent + it->max_descent);
	  row->phys_ascent = max (row->phys_ascent, it->max_phys_ascent);
	  row->phys_height = max (row->phys_height,
				  it->max_phys_ascent + it->max_phys_descent);

(This is the mainline of the algorithm; you will see that there are
few special cases where we don't take the values from the font glyphs,
but from other sources.  Perhaps this could explain the strange
situation you see with this particular font.)

So now the question becomes: which of the characters on the window's
first screen line, or some other condition there, causes the
row->phys_ascent value become larger than row->ascent?  And why does
this not happen in a non-Cairo build?

Thanks.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-11-01 18:15:04 +0200, Eli Zaretskii wrote:
> Interesting.  Once you understand where did the value 12 come from,
> perhaps you could see how things are different in a non-Cairo build.

It appears that Cairo uses floating point with poor rounding control
(see below). I suppose that the non-cairo driver keeps integers.

> Let me describe how row->phys_ascent is computed, so that you could
> take a closer look.
[...]

Yes, this is what I've found:

The row->phys_ascent comes from function display_line, in the loop
generating characters:

      if (/* Not a newline.  */
          nglyphs > 0
          /* Glyphs produced fit entirely in the line.  */
          && it->current_x < it->last_visible_x)
        {
[...]
          row->phys_ascent = max (row->phys_ascent, it->max_phys_ascent);
[...]
        }

At the first iteration, row->phys_ascent is changed from 0 to 12.
So, it comes from it->max_phys_ascent, which is set to 12 by

      PRODUCE_GLYPHS (it);

earlier in the loop. In this context (X protocol), this macro calls
gui_produce_glyphs (defined in xdisp.c).

In gui_produce_glyphs, this is case it->what == IT_CHARACTER, with
it->char_to_display == 'F'; pcm is true and it->phys_ascent is set
to 12 by

              it->phys_ascent = pcm->ascent + boff;

where pcm->ascent = 12 and boff = 0, while for Emacs without cairo,
pcm->ascent = 11 (and boff = 0) as expected.

With size 14 (with or without cairo), one has pcm->ascent = 12.

Thus the issue comes from pcm->ascent. It is set by get_per_char_metric,
where char2b = 40. With cairo, it calls function ftcrfont_text_extents
(defined in ftcrfont.c), which calls ftcrfont_glyph_extents, which sets
metrics->ascent to 12 from the cache.

When the cache is filled with

      cache->ascent = ceil (- extents.y_bearing);

extents.y_bearing (whose type is double) is equal to:

Font size 13: -0x1.6000000000001p+3 ≈ -11.000000000000002
Font size 14: -0x1.8p+3 = -12

With ceil(), 11.000000000000002 rounds to 12, while the expected value
is 11. A rounding issue, as I guessed at

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

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sun, 1 Nov 2020 18:32:40 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> When the cache is filled with
> 
>       cache->ascent = ceil (- extents.y_bearing);
> 
> extents.y_bearing (whose type is double) is equal to:
> 
> Font size 13: -0x1.6000000000001p+3 ≈ -11.000000000000002
> Font size 14: -0x1.8p+3 = -12
> 
> With ceil(), 11.000000000000002 rounds to 12, while the expected value
> is 11. A rounding issue, as I guessed at
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44284#29

Thanks.  Do you have a suggestion for a fix?

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-11-01 19:43:12 +0200, Eli Zaretskii wrote:
> > When the cache is filled with
> > 
> >       cache->ascent = ceil (- extents.y_bearing);
> > 
> > extents.y_bearing (whose type is double) is equal to:
> > 
> > Font size 13: -0x1.6000000000001p+3 ≈ -11.000000000000002
> > Font size 14: -0x1.8p+3 = -12
> > 
> > With ceil(), 11.000000000000002 rounds to 12, while the expected value
> > is 11. A rounding issue, as I guessed at
> > 
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44284#29
> 
> Thanks.  Do you have a suggestion for a fix?

Well, I think that there are 3 potential issues.

1. That fact that here, extents.y_bearing is slightly incorrect,
which appears to be a bug in Cairo.

If I understand correctly, Cairo can handle any font size (not just
integer ones), e.g. with scalable fonts. Thus rounding cannot be
avoided. Ideally one should have correct rounding on each visible
result, but I suppose that this can be very complex and slow down
applications, so that in general, an indeterminate rounding error
may be acceptable, and applications / rendering algorithms should
cope with that (when discontinuous functions are involved, such as
rounding to an integer): if continuity is preserved in some way,
the user will never see an error of, say, 2^(-45) pixel.

Now, there's the particular case of integer font sizes, in particular
with X fonts, and one may want to preserve integers exactly on the
Cairo side. I don't know whether this can be done or there are tricky
issues.

2. The fact that the cache->ascent integer gets incorrect in Emacs.

This could be fixed either on the Cairo side (see above) or on the
application (Emacs) side. In the latter case:

First, if Emacs knows that under some condition, extents.y_bearing
should be an integer, it could round to nearest. For instance, if
this is an X font like here, is this necessarily the case?

Alternatively, Emacs could use some heuristic: if extents.y_bearing
is very close to an integer, assume that it should be this integer.
This is rather ugly as this might yield unexpected results in some
applications, but would this be OK in Emacs?

3. The fact that row->phys_ascent > row->ascent in compute_line_metrics
yields an incorrect behavior. This is about the following comment:

      /* If first line's physical ascent is larger than its logical
         ascent, use the physical ascent, and make the row taller.
         This makes accented characters fully visible.  */

Or is the bug I've reported about that is specific to the incorrect
cache->ascent issue (item 2), in which case fixing (2) would be
sufficient for everyone?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sun, 1 Nov 2020 19:34:58 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> > Thanks.  Do you have a suggestion for a fix?
> 
> Well, I think that there are 3 potential issues.
> 
> 1. That fact that here, extents.y_bearing is slightly incorrect,
> which appears to be a bug in Cairo.

Probably (I'm not an expert on Cairo), but if so, this is out of our
control.  For all I know, Cairo developers could have decided to drop
support for the font family you are using.

> 2. The fact that the cache->ascent integer gets incorrect in Emacs.
> 
> This could be fixed either on the Cairo side (see above) or on the
> application (Emacs) side. In the latter case:
> 
> First, if Emacs knows that under some condition, extents.y_bearing
> should be an integer, it could round to nearest. For instance, if
> this is an X font like here, is this necessarily the case?
> 
> Alternatively, Emacs could use some heuristic: if extents.y_bearing
> is very close to an integer, assume that it should be this integer.
> This is rather ugly as this might yield unexpected results in some
> applications, but would this be OK in Emacs?

It would be okay, I think: we have a few kludgey workarounds for
similar issues in other libraries.

I thought about something like using ceil (VALUE - 1/128) or maybe
even 1/256, on the assumption that the original integer value cannot
be of a greater granularity (the non-Cairo code uses 1/64).

> 3. The fact that row->phys_ascent > row->ascent in compute_line_metrics
> yields an incorrect behavior. This is about the following comment:
> 
>       /* If first line's physical ascent is larger than its logical
>          ascent, use the physical ascent, and make the row taller.
>          This makes accented characters fully visible.  */

This is not a bug, we must keep that code.  It just isn't supposed to
fire in your case.

> Or is the bug I've reported about that is specific to the incorrect
> cache->ascent issue (item 2), in which case fixing (2) would be
> sufficient for everyone?

Yes, we should solve item 2.

Thanks.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-11-01 20:47:04 +0200, Eli Zaretskii wrote:
> > 3. The fact that row->phys_ascent > row->ascent in compute_line_metrics
> > yields an incorrect behavior. This is about the following comment:
> > 
> >       /* If first line's physical ascent is larger than its logical
> >          ascent, use the physical ascent, and make the row taller.
> >          This makes accented characters fully visible.  */
> 
> This is not a bug, we must keep that code.  It just isn't supposed to
> fire in your case.

For this one, I meant that if the first row is made taller for some
good reason, then this shouldn't yields recentering when scrolling
upward with the mouse wheel, and (move-to-window-line -1) should put
the cursor on the last fully visible display line of the window, as
documented.

Solving (2) would no longer trigger this code in my case, but you
should make sure that this code, which is still useful in some other
cases, behaves correctly with various Emacs features.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sun, 01 Nov 2020 20:47:04 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 44284@debbugs.gnu.org
> 
> > Alternatively, Emacs could use some heuristic: if extents.y_bearing
> > is very close to an integer, assume that it should be this integer.
> > This is rather ugly as this might yield unexpected results in some
> > applications, but would this be OK in Emacs?
> 
> It would be okay, I think: we have a few kludgey workarounds for
> similar issues in other libraries.
> 
> I thought about something like using ceil (VALUE - 1/128) or maybe
> even 1/256, on the assumption that the original integer value cannot
> be of a greater granularity (the non-Cairo code uses 1/64).

No further comments, so I pushed such a fix to the master branch, and
I'm closing this bug report.  Many thanks for your help in debugging
this problem.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-11-07 10:29:17 +0200, Eli Zaretskii wrote:
> > Date: Sun, 01 Nov 2020 20:47:04 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 44284@debbugs.gnu.org
> > 
> > > Alternatively, Emacs could use some heuristic: if extents.y_bearing
> > > is very close to an integer, assume that it should be this integer.
> > > This is rather ugly as this might yield unexpected results in some
> > > applications, but would this be OK in Emacs?
> > 
> > It would be okay, I think: we have a few kludgey workarounds for
> > similar issues in other libraries.
> > 
> > I thought about something like using ceil (VALUE - 1/128) or maybe
> > even 1/256, on the assumption that the original integer value cannot
> > be of a greater granularity (the non-Cairo code uses 1/64).
> 
> No further comments, so I pushed such a fix to the master branch, and
> I'm closing this bug report.  Many thanks for your help in debugging
> this problem.

I've just tested, and I confirm that this completely fixes the bug.
Thanks.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sat, 7 Nov 2020 11:35:35 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> > No further comments, so I pushed such a fix to the master branch, and
> > I'm closing this bug report.  Many thanks for your help in debugging
> > this problem.
> 
> I've just tested, and I confirm that this completely fixes the bug.
> Thanks.

Thanks for testing the fix.

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sat, 31 Oct 2020 23:43:24 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> window_scroll_pixel_based is not called at all, neither window_scroll
> is.

Are you sure?  That's very strange; it does get invoked on my system.
This happens because turning the mouse wheel invokes mwheel-scroll,
which calls the value of mwheel-scroll-up/down-function, whose default
value is scroll-up/down, and those functions call scroll_command, which
calls window_scroll, which on GUI frames calls
window_scroll_pixel_based.  Which part of this chain doesn't happen on
your system?

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Vincent Lefevre]

On 2020-11-01 17:55:48 +0200, Eli Zaretskii wrote:
> > Date: Sat, 31 Oct 2020 23:43:24 +0100
> > From: Vincent Lefevre <vincent@vinc17.net>
> > Cc: 44284@debbugs.gnu.org
> > 
> > window_scroll_pixel_based is not called at all, neither window_scroll
> > is.
> 
> Are you sure?  That's very strange; it does get invoked on my system.
> This happens because turning the mouse wheel invokes mwheel-scroll,
[...]

I meant, when I started to get unexpected values. Then yes, maybe
(I haven't got that far), which would explain why I can put later
the cursor on the last line.

Anyway, this is not the cause of the bug. See my following mail...

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Fri, 30 Oct 2020 21:34:53 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> I've found the cause of this issue: with the culprit font, it is
> not always possible to put the text cursor on the last line in
> the window, either with a mouse click or with the down arrow:
> Emacs scrolls the text so that the cursor is at the center of
> the window. Why/when this occurs remains to be determined (is
> there some rounding involved?).

Emacs always requires that the line where point is should be fully
visible.  This is standard Emacs behavior, nothing new and nothing
specific to any special font.

> When the bug does not occur with the mouse wheel, the cursor is
> put on the last line. But with the culprit font, I suppose that
> the above issue causes another scroll in the opposite direction,
> hence the observed behavior.

I suspected that much, but I cannot reproduce this.  When I arrange
for the font to be of size that causes the last line of the window to
be only partially visible, scrolling with the mouse always leaves
point on the line above the last, which is fully visible.  I couldn't
cause the situation you describe, no matter what I tried.

So there's some other factor at work here that somehow forces this
aberrant behavior, and a reproduction recipe is needed to identify
the code which causes it.