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

[Eli Zaretskii <eliz@gnu.org>]

> 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.