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

[Vincent Lefevre <vincent@vinc17.net>]

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

On 2025-01-04 16:36:20 +0200, Eli Zaretskii wrote:
> > 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?

The main problem is not a display problem, but the fact that the
cursor (point) is not at the end of the buffer.

I've attached a screenshot to show what I get. The cursor (not visible
on the screenshot) is just below the yellow area, on the first column.
Note that the last line is only partly visible: one just has the top
of the "x".

Concerning your other question,

  M-: (goto-char (point-max)) RET

after C-SPC puts the cursor at the end of the buffer, as I expect.
But, just for confirmation that the cause of the difference is not
due to the minibuffer,

  M-: (end-of-buffer) RET

also after C-SPC is still affected by the problem.

BTW, I thought that end-of-buffer were equivalent to
(goto-char (point-max)), except for the "they set the mark and
display messages in the echo area" part.

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

This was taken from https://emacs.stackexchange.com/q/17205/29118
(the goal was to prevent a fallback to a font with different metrics,
breaking column alignments; well, at least this was working for
math characters, IIRC).

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

I'm not sure I understand your question. But, for instance, if
I replace 黒 by one of the other two characters (x or 岨), the
problem doesn't occur.

Note: Just after opening the file, if I use the <down>, after the
scrolling, C-u C-x = over 岨 says

  ftcrhb:-GOOG-Noto Sans CJK KR-regular-normal-normal-*-20-*-*-*-*-0-iso10646-1 (#x3E7C)

even though the font has not changed and the character 黒 is displayed.
But C-SPC makes the font change, while I would expect no changes. This
is strange.

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

[-- Attachment #2: 20250104-193122.png --]
[-- Type: image/png, Size: 28052 bytes --]