GNU bug report logs -
#75352
29.4; end-of-buffer is buggy after set-mark-command with some fonts
Previous Next
Full log
Message #14 received at 75352 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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)
[20250104-193122.png (image/png, attachment)]
This bug report was last modified 161 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.