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

Previous Next

To reply to this bug, email your comments to 75352 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.4; end-of-buffer is buggy after set-mark-command with some fonts
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.

To reproduce:

First, I have in my X resources:

Xft.dpi:                132
Emacs.font:             DejaVu Sans Mono-10
Emacs*geometry:         80x48

(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

with the following file (49 lines):

x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
岨
岨
岨
岨
岨
岨
岨
岨
岨
岨
岨
岨
岨
岨
岨
岨
岨
黒
x

Then type: C-SPC M->

Here, the cursor is placed on line 35 instead of line 50.

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)

Note also that if I first go to the end of the buffer and go back to
the beginning, the problem is not reproducible.


In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43,
 cairo version 1.18.2) of 2024-12-08, modified by Debian built on sbuild
Windowing system distributor 'The X.Org Foundation', version 11.0.12101015
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --with-cairo --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -Werror=implicit-function-declaration
 -ffile-prefix-map=/build/reproducible-path/emacs-29.4+1=.
 -fstack-protector-strong -fstack-clash-protection -Wformat
 -Werror=format-security -fcf-protection -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: C.UTF-8
  value of $LC_TIME: en_DK.utf8
  value of $LANG: C.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-14/llvm-mode
/usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-14/tablegen-mode
/usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-14/emacs
/usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-15/llvm-mode
/usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-15/tablegen-mode
/usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-15/emacs
/usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-16/llvm-mode
/usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-16/tablegen-mode
/usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-16/emacs
/usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-17/llvm-mode
/usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-17/tablegen-mode
/usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-17/emacs
/usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-18/llvm-mode
/usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-18/tablegen-mode
/usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-18/emacs
/usr/share/emacs/site-lisp/llvm-13/llvm-mode hides /usr/share/emacs/site-lisp/llvm-19/llvm-mode
/usr/share/emacs/site-lisp/llvm-13/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-19/tablegen-mode
/usr/share/emacs/site-lisp/llvm-13/emacs hides /usr/share/emacs/site-lisp/llvm-19/emacs
/usr/share/emacs/site-lisp/elpa/po-mode-0.22.5/po-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.22.5/po-mode-autoloads
/usr/share/emacs/site-lisp/elpa/po-mode-0.22.5/po-mode hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.22.5/po-mode
/usr/share/emacs/site-lisp/elpa/po-mode-0.22.5/po-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.22.5/po-mode-pkg
/usr/share/emacs/site-lisp/flim/sasl hides /usr/share/emacs/29.4/lisp/net/sasl
/usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/29.4/lisp/language/thai-word

Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr warnings
rx cl-extra help-mode cus-start time cc-styles cc-align cc-engine
cc-vars cc-defs w3m-load mmm-auto mmm-vars mmm-utils mmm-compat cus-edit
pp cus-load icons wid-edit po-mode-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 155726 7823)
 (symbols 48 11927 1)
 (strings 32 39042 3056)
 (string-bytes 1 1261112)
 (vectors 16 24541)
 (vector-slots 8 695353 82229)
 (floats 8 53 24)
 (intervals 56 317 0)
 (buffers 984 12))

Message #8 received at 75352 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 75352 <at> debbugs.gnu.org
Subject: Re: bug#75352: 29.4;
 end-of-buffer is buggy after set-mark-command with some fonts
Date: Sat, 04 Jan 2025 16:36:20 +0200

> From: Vincent Lefevre <vincent <at> 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.

Message #11 received at 75352 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: vincent <at> vinc17.net
Cc: 75352 <at> debbugs.gnu.org
Subject: Re: bug#75352: 29.4;
 end-of-buffer is buggy after set-mark-command with some fonts
Date: Sat, 04 Jan 2025 16:43:52 +0200

> Cc: 75352 <at> debbugs.gnu.org
> Date: Sat, 04 Jan 2025 16:36:20 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> 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.

And one more question: If, instead of M->, you use

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

do you see the same behavior, or do you see something different?

Message #14 received at 75352 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75352 <at> debbugs.gnu.org
Subject: Re: bug#75352: 29.4; end-of-buffer is buggy after set-mark-command
 with some fonts
Date: Sat, 4 Jan 2025 20:25:04 +0100

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

Message #17 received at 75352 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 75352 <at> debbugs.gnu.org
Subject: Re: bug#75352: 29.4; end-of-buffer is buggy after set-mark-command
 with some fonts
Date: Sat, 04 Jan 2025 22:00:36 +0200

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

Message #20 received at 75352 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75352 <at> debbugs.gnu.org
Subject: Re: bug#75352: 29.4; end-of-buffer is buggy after set-mark-command
 with some fonts
Date: Sun, 5 Jan 2025 23:55:26 +0100

On 2025-01-04 22:00:36 +0200, Eli Zaretskii wrote:
> > Date: Sat, 4 Jan 2025 20:25:04 +0100
> > From: Vincent Lefevre <vincent <at> vinc17.net>
> > Cc: 75352 <at> 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.

For the end user, this is very surprising (even with strange font
settings, something that is not documented, AFAIK, and for which
one gets no errors or warnings).

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

I just said that the cursor was on line 35, which is the line that is
just below the yellow area (unless Emacs gives incorrect information
on the line number).

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

I want something that would be applied for every available glyphs,
so that the display looks somewhat typographically consistent.

Note that the line I gave was just for a simple example. In my actual
settings, I provide other fonts: DejaVu Sans Mono and DejaVu Sans.
Since DejaVu Sans provides a lot of glyphs for various scripts,
I had initially thought that this would be complete for my needs
(though DejaVu Sans has the drawback to change the width of the
cells).

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

IMHO, in such a case (when used with end-of-buffer), Emacs should scroll,
keeping the point position.

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

Message #23 received at 75352 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 75352 <at> debbugs.gnu.org
Subject: Re: bug#75352: 29.4; end-of-buffer is buggy after set-mark-command
 with some fonts
Date: Mon, 06 Jan 2025 15:15:47 +0200

> Date: Sun, 5 Jan 2025 23:55:26 +0100
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Cc: 75352 <at> debbugs.gnu.org
> 
> > > 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.
> 
> For the end user, this is very surprising (even with strange font
> settings, something that is not documented, AFAIK, and for which
> one gets no errors or warnings).

Supporting variable-height lines of text comes with rare situations
where this is necessary.

> > And yes, if the font changes, what was inside the viewport can become
> > outside, and that could cause Emacs move point.
> 
> IMHO, in such a case (when used with end-of-buffer), Emacs should scroll,
> keeping the point position.

It tries, but that is not always possible.

Anyway, to look into this further, I need a recipe that will reproduce
the problem with fonts I can install.  Until now, I was unable to see
anything like you describe, and I'm not on Debian to begin with.

Message #26 received at 75352 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75352 <at> debbugs.gnu.org
Subject: Re: bug#75352: 29.4; end-of-buffer is buggy after set-mark-command
 with some fonts
Date: Mon, 6 Jan 2025 14:51:19 +0100

On 2025-01-06 15:15:47 +0200, Eli Zaretskii wrote:
> > Date: Sun, 5 Jan 2025 23:55:26 +0100
> > From: Vincent Lefevre <vincent <at> vinc17.net>
> > Cc: 75352 <at> debbugs.gnu.org
> > 
> > > > 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.
> > 
> > For the end user, this is very surprising (even with strange font
> > settings, something that is not documented, AFAIK, and for which
> > one gets no errors or warnings).
> 
> Supporting variable-height lines of text comes with rare situations
> where this is necessary.

Note that variable-height lines occur even without my
set-fontset-font settings. For instance, consider the following
character: ⎷ (U+23B7 RADICAL SYMBOL BOTTOM). So this is not due
to "strange font settings".

> > > And yes, if the font changes, what was inside the viewport can become
> > > outside, and that could cause Emacs move point.
> > 
> > IMHO, in such a case (when used with end-of-buffer), Emacs should scroll,
> > keeping the point position.
> 
> It tries, but that is not always possible.

Well, this is handled correctly by (goto-char (point-max)), so I don't
see why this is not always possible.

> Anyway, to look into this further, I need a recipe that will reproduce
> the problem with fonts I can install.  Until now, I was unable to see
> anything like you describe, and I'm not on Debian to begin with.

Perhaps consider the character I've mentioned above.

I could also try to have a look when I have some time.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.