bug#75352: 29.4; end-of-buffer is buggy after set-mark-command with some fonts

[Eli Zaretskii <eliz@gnu.org>]

> From: Vincent Lefevre <vincent@vinc17.net>
> Date: Sat, 04 Jan 2025 15:11:14 +0100
> 
> 
> With the Noto Mono font and a file with some Japanese characters
> (I suspect that the reason of the need of such characters is that
> they slightly modify the cell height, and the font can change by
> just moving the cursor; see below), after set-mark-command (C-SPC),
> end-of-buffer (M->) does not go to the end of the buffer.

end-of-buffer scrolls the window to show EOB not-quite-at-the-bottom
of the window.  So what you describe can happen with unusual fonts.

Why is that a problem?

> (Due to the following setting, which is important, I don't know whether
> the above Emacs.font matters.)
> 
> $ emacs -Q --eval="(set-fontset-font t 'unicode (font-spec :name \"Noto Mono\"))" file

This set-fontset-font setting is not a good idea: it tells Emacs that
the named font can display _any_ Unicode character, which is usually
not true: almost all fonts support only a subset of Unicode.

> Then type: C-SPC M->
> 
> Here, the cursor is placed on line 35 instead of line 50.

If the last characters in the file are shown taller than the others,
it could happen that the last line is not fully visible, and then
Emacs will scroll the display

> Note: Even without set-mark-command, once the 黒 character (line 48)
> gets displayed, the font used for 岨 changes and the character cells
> get taller. I've wondering whether this can confuse Emacs. At least,
> this character 黒 is important to reproduce the problem.
> 
> By using C-u C-x =, I get
>   * over x:
>     ftcrhb:-PfEd-DejaVu Sans Mono-regular-normal-normal-*-18-*-*-*-m-0-iso10646-1 (#x5B)
>   * over 岨 before 黒 gets displayed:
>     ftcrhb:-PfEd-AR PL UMing TW MBE-light-normal-normal-*-18-*-*-*-*-0-iso10646-1 (#x159C)
>   * over 黒 (and same font over 岨 after 黒 gets displayed):
>     ftcrhb:-GOOG-Noto Sans CJK KR-regular-normal-normal-*-18-*-*-*-*-0-iso10646-1 (#xB7AC)

So there are at least 3 different specific fonts involved, and in
addition the region's highlight seems to have some effect, and the
frame needs to have a particular geometry.  Can you tell why it is
important to understand why what you see happens in that particular
case?  We will likely find that Emacs behaves as expected due to the
metrics of the fonts.