GNU bug report logs - #57087
29.0.50; (face-at-point nil t) does not return all faces when hl-line-mode is active

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57087 in the body.
You can then email your comments to 57087 AT debbugs.gnu.org in the normal way.

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

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

From: dalanicolai <dalanicolai <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; (face-at-point nil t) does not return all faces when
 hl-line-mode is active
Date: Tue, 9 Aug 2022 20:55:13 +0200

[Message part 1 (text/plain, inline)]

Open some elisp (.el) buffer, place the cursor on some fontified keyword
(e.g. 'defun') and do `M-: (face-at-point nil t)`. Now activate `(M-x)
hl-line-mode` and again do `M-: (face-at-point nil t)`. The list shows
only the `hl-line` face, while the function its docstring says it should
return multiple faces.

When edebugging `face-at-point`, even though `hl-line-mode` is active,
the function returns only the char its face (and not `hl-line`).

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34,
cairo version 1.17.6)
 of 2022-06-12 built on fedora
Repository revision: c1829b307cffce046bec6fcbdff03dbab9f4b562
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --with-modules --with-cairo --with-native-compilation
 --with-json'

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

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug comp comp-cstr warnings rx cl-seq
cl-macs cl-extra help-mode message mailcap yank-media rmc puny dired
dired-loaddefs rfc822 mml mml-sec password-cache 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 hl-line vc-git
diff-mode easy-mmode vc-dispatcher cl-loaddefs cl-lib seq gv subr-x
byte-opt bytecomp byte-compile cconv iso-transl tooltip 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 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 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 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 89094 14677)
 (symbols 48 7738 0)
 (strings 32 21901 915)
 (string-bytes 1 769799)
 (vectors 16 16342)
 (vector-slots 8 317353 20223)
 (floats 8 30 95)
 (intervals 56 499 5)
 (buffers 992 15))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: dalanicolai <dalanicolai <at> gmail.com>
Cc: 57087 <at> debbugs.gnu.org
Subject: Re: bug#57087: 29.0.50;
 (face-at-point nil t) does not return all faces when hl-line-mode is
 active
Date: Tue, 09 Aug 2022 22:20:48 +0300

tags 57087 notabug
thanks

> From: dalanicolai <dalanicolai <at> gmail.com>
> Date: Tue, 9 Aug 2022 20:55:13 +0200
> 
> Open some elisp (.el) buffer, place the cursor on some fontified keyword
> (e.g. 'defun') and do `M-: (face-at-point nil t)`. Now activate `(M-x)
> hl-line-mode` and again do `M-: (face-at-point nil t)`. The list shows
> only the `hl-line` face, while the function its docstring says it should
> return multiple faces.

This is a misunderstanding of what the doc string means when it says
"faces".  It doesn't mean that you should see more than one face in
the above situation.

This is not a bug, it's just that your expectations from what
face-at-point can do are incorrect.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57087 <at> debbugs.gnu.org, dalanicolai <dalanicolai <at> gmail.com>
Subject: Re: bug#57087: 29.0.50; (face-at-point nil t) does not return all
 faces when hl-line-mode is active
Date: Tue, 09 Aug 2022 21:35:25 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> This is a misunderstanding of what the doc string means when it says
> "faces".  It doesn't mean that you should see more than one face in
> the above situation.
>
> This is not a bug, it's just that your expectations from what
> face-at-point can do are incorrect.

Then I think this doc string needs clarification, at least:

---
face-at-point is a byte-compiled Lisp function in faces.el.

(face-at-point &optional THING MULTIPLE)

Return the face of the character after point.
If it has more than one face, return the first one.
If THING is non-nil try first to get a face name from the buffer.
IF MULTIPLE is non-nil, return a list of all faces.
Return nil if there is no face.
---

I think it sounds like it would be more useful if it did indeed return
all the faces at point instead of just the face(s) from either the
overlay or the face(s) from the text property.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57087 <at> debbugs.gnu.org, dalanicolai <at> gmail.com
Subject: Re: bug#57087: 29.0.50; (face-at-point nil t) does not return all
 faces when hl-line-mode is active
Date: Wed, 10 Aug 2022 05:28:33 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dalanicolai <dalanicolai <at> gmail.com>,  57087 <at> debbugs.gnu.org
> Date: Tue, 09 Aug 2022 21:35:25 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > This is a misunderstanding of what the doc string means when it says
> > "faces".  It doesn't mean that you should see more than one face in
> > the above situation.
> >
> > This is not a bug, it's just that your expectations from what
> > face-at-point can do are incorrect.
> 
> Then I think this doc string needs clarification, at least:

Yes, probably.  However, "return the first one" doesn't tell which one
this would be.  Also "character has more than one face" is inaccurate,
we should say "more than one source of face information" or somesuch.

> I think it sounds like it would be more useful if it did indeed return
> all the faces at point instead of just the face(s) from either the
> overlay or the face(s) from the text property.

AFAICT, there's only one user of MULTIPLE, and that is org.el, so we
should ask them what they expect.  There's always a possibility to add
a new function, say faces-at-point.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57087 <at> debbugs.gnu.org, dalanicolai <at> gmail.com
Subject: Re: bug#57087: 29.0.50; (face-at-point nil t) does not return all
 faces when hl-line-mode is active
Date: Fri, 12 Aug 2022 15:55:35 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Yes, probably.  However, "return the first one" doesn't tell which one
> this would be.  Also "character has more than one face" is inaccurate,
> we should say "more than one source of face information" or somesuch.

Yup.  And `thing' is an unfortunate argument name, since people might
interpret that as the face property should be gotten from that thing (as
with get-text-property and friends with `object').

>> I think it sounds like it would be more useful if it did indeed return
>> all the faces at point instead of just the face(s) from either the
>> overlay or the face(s) from the text property.
>
> AFAICT, there's only one user of MULTIPLE, and that is org.el, so we
> should ask them what they expect.  There's always a possibility to add
> a new function, say faces-at-point.

Yes, I think perhaps adding a new function like that might make more
sense, because `face-at-point' seems like a very DWIM-ish function with
unclear semantics (like preferring the `read-face-name' over `face'
property, etc).

So I've now just explained this in the doc string.  I think the function
is basically fine as is -- it works well as a prompt default function.

Previous Next

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