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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 4 Jan 2025 20:25:04 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 75352@debbugs.gnu.org
> 
> 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.

My point is that M-> doesn't guarantee that.

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

Didn't you say that point then moves back into the viewport, and is
set to line 35?  Or what am I missing.

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

My intent in asking that was to make the point that they are NOT
equivalent.  If you look at the code of end-of-buffer, you will see
that after going to EOB it does something else.  My guess is that that
something, together with the strange font setup you have, is the
reason for the behavior you see.

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

That is not how you do that.  You should instead use set-fontset-font
to specify a particular suitable font for the 'mathematical' script.

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

C-SPC makes characters display in a different face, so strange things
can happen if your fontset setup is incorrect (which it is because of
the above setting in the --eval command-line argument).  Just don't do
that.

And yes, if the font changes, what was inside the viewport can become
outside, and that could cause Emacs move point.