GNU bug report logs - #43265
28.0.50; Inconsistent fontifying in elisp-mode

Previous Next

Package: emacs;

Reported by: Mauro Aranda <maurooaranda <at> gmail.com>

Date: Mon, 7 Sep 2020 20:06:02 UTC

Severity: minor

Tags: confirmed

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 07 Sep 2020 20:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mauro Aranda <maurooaranda <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 07 Sep 2020 20:06:02 GMT) Full text and rfc822 format available.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Mon, 7 Sep 2020 17:05:01 -0300
[Message part 1 (text/plain, inline)]
To reproduce:

emacs -Q
In the scratch buffer type:

(condition-case nil
    (fail-badly)
  (error (when foo t)))

I don't see WHEN with font-lock-keyword-face.  However:

(condition-case nil
    (fail-badly)
  (error (if foo t)))

IF has font-lock-keyword-face.


In GNU Emacs 28.0.50 (build 181, x86_64-pc-linux-gnu, cairo version 1.15.10)
 of 2020-09-07 built on tbb-desktop
Repository revision: 0ebe2678002ffb82a25311c56cbc4b8ba3bd5fa1
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Ubuntu 18.04.5 LTS

Configured using:
 'configure --with-x-toolkit=no'

Configured features:
XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB OLDXMENU X11 XDBE XIM MODULES
THREADS PDUMPER

Important settings:
  value of $LC_MONETARY: es_AR.UTF-8
  value of $LC_NUMERIC: es_AR.UTF-8
  value of $LC_TIME: es_AR.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr mule-util info emacsbug message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date subr-x pcase misearch
multi-isearch vc-git diff-mode easy-mmode bug-reference pp wid-edit
descr-text help-fns radix-tree cl-print debug backtrace help-mode
easymenu find-func cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic 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 charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo x multi-tty make-network-process emacs)

Memory information:
((conses 16 133020 8093)
 (symbols 48 8406 1)
 (strings 32 28861 5704)
 (string-bytes 1 864362)
 (vectors 16 14411)
 (vector-slots 8 187982 17929)
 (floats 8 37 39)
 (intervals 56 17238 0)
 (buffers 992 17))
[Message part 2 (text/html, inline)]

Severity set to 'minor' from 'normal' Request was from Stefan Kangas <stefankangas <at> gmail.com> to control <at> debbugs.gnu.org. (Tue, 08 Sep 2020 07:27:02 GMT) Full text and rfc822 format available.

Added tag(s) confirmed. Request was from Stefan Kangas <stefankangas <at> gmail.com> to control <at> debbugs.gnu.org. (Tue, 08 Sep 2020 07:27:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Fri, 22 Jan 2021 19:33:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 43265 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Fri, 22 Jan 2021 20:32:38 +0100
Mauro Aranda <maurooaranda <at> gmail.com> writes:

> To reproduce:
>
> emacs -Q
> In the scratch buffer type:
>
> (condition-case nil
>     (fail-badly)
>   (error (when foo t)))
>
> I don't see WHEN with font-lock-keyword-face.  However:
>
> (condition-case nil
>     (fail-badly)
>   (error (if foo t)))
>
> IF has font-lock-keyword-face.

This is the bit that determines whether to give something a keyword-face:

(defun lisp--el-match-keyword (limit)
  ;; FIXME: Move to elisp-mode.el.
  (catch 'found
    (while (re-search-forward
            (eval-when-compile
              (concat "(\\(" lisp-mode-symbol-regexp "\\)\\_>"))
            limit t)
      (let ((sym (intern-soft (match-string 1))))
	(when (or (special-form-p sym)
		  (and (macrop sym)
                       (not (get sym 'no-font-lock-keyword))
                       (not (lisp--el-non-funcall-position-p
                             (match-beginning 0)))))
	  (throw 'found t))))))

All special forms get it (`if' is a special form), but macros (like
`when') only gets it if we're in a funcall position:

(defun lisp--el-non-funcall-position-p (pos)
  "Heuristically determine whether POS is an evaluated position."

[...]

                  (and (eq parent 'condition-case)
                       (progn
                         (forward-sexp 2)
                         (< (point) pos))))))))))


And this doesn't count any of the error clauses as being in a funcall
position, so no macros in those get a keyword-face.  

I think.  I've added Stefan M to the CCs.

If that's the correct analysis, then fixing this shouldn't be too hard,
I think?  Just add some extra code in the `condition-case' bit to catch
this case?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Fri, 22 Jan 2021 20:12:02 GMT) Full text and rfc822 format available.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43265 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Fri, 22 Jan 2021 17:11:22 -0300
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> To reproduce:
>>
>> emacs -Q
>> In the scratch buffer type:
>>
>> (condition-case nil
>>     (fail-badly)
>>   (error (when foo t)))
>>
>> I don't see WHEN with font-lock-keyword-face.  However:
>>
>> (condition-case nil
>>     (fail-badly)
>>   (error (if foo t)))
>>
>> IF has font-lock-keyword-face.
>
> This is the bit that determines whether to give something a keyword-face:
>
> (defun lisp--el-match-keyword (limit)
>   ;; FIXME: Move to elisp-mode.el.
>   (catch 'found
>     (while (re-search-forward
>             (eval-when-compile
>               (concat "(\\(" lisp-mode-symbol-regexp "\\)\\_>"))
>             limit t)
>       (let ((sym (intern-soft (match-string 1))))
> 	(when (or (special-form-p sym)
> 		  (and (macrop sym)
>                        (not (get sym 'no-font-lock-keyword))
>                        (not (lisp--el-non-funcall-position-p
>                              (match-beginning 0)))))
> 	  (throw 'found t))))))
>
> All special forms get it (`if' is a special form), but macros (like
> `when') only gets it if we're in a funcall position:
>
> (defun lisp--el-non-funcall-position-p (pos)
>   "Heuristically determine whether POS is an evaluated position."
>
> [...]
>
>                   (and (eq parent 'condition-case)
>                        (progn
>                          (forward-sexp 2)
>                          (< (point) pos))))))))))
>
>
> And this doesn't count any of the error clauses as being in a funcall
> position, so no macros in those get a keyword-face.  
>
> I think.  I've added Stefan M to the CCs.
>
> If that's the correct analysis, then fixing this shouldn't be too hard,
> I think?  Just add some extra code in the `condition-case' bit to catch
> this case?

Thanks for taking a look at this report, I hope it's easy to fix.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Fri, 22 Jan 2021 22:33:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43265 <at> debbugs.gnu.org, Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Fri, 22 Jan 2021 17:32:20 -0500
> All special forms get it (`if' is a special form), but macros (like
> `when') only gets it if we're in a funcall position:

Not sure why that is.  Seems like an accident.

> (defun lisp--el-non-funcall-position-p (pos)
>   "Heuristically determine whether POS is an evaluated position."
>
> [...]
>
>                   (and (eq parent 'condition-case)
>                        (progn
>                          (forward-sexp 2)
>                          (< (point) pos))))))))))
>
>
> And this doesn't count any of the error clauses as being in a funcall
> position, so no macros in those get a keyword-face.  

Sounds like a bug.  Note that in

    (condition-case nil
        (foo)
      (error (when a (when b c))))

the second `when` gets the keyword face, as it should.
BTW I suspect that part of the reason for this bug is because of the
need to avoid using the keyword face on the `when` of:

    (condition-case nil
        (foo)
      ((when error) ...))

Adding corresponding tests for these things would be great.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Sat, 23 Jan 2021 18:44:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 43265 <at> debbugs.gnu.org, Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Sat, 23 Jan 2021 19:42:52 +0100
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> All special forms get it (`if' is a special form), but macros (like
>> `when') only gets it if we're in a funcall position:
>
> Not sure why that is.  Seems like an accident.

The special form bit, or the macro bit?  :-)

Since special forms are always font-locked as keywords when appearing as
the first element in a list, you get stuff like:

[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
So if would perhaps make sense to also do the `funcall-position-p' for
special forms?

> Sounds like a bug.  Note that in
>
>     (condition-case nil
>         (foo)
>       (error (when a (when b c))))
>
> the second `when` gets the keyword face, as it should.

Because then `condition-case' isn't the parent, presumably.

> BTW I suspect that part of the reason for this bug is because of the
> need to avoid using the keyword face on the `when` of:
>
>     (condition-case nil
>         (foo)
>       ((when error) ...))
>
> Adding corresponding tests for these things would be great.

Indeed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Sat, 23 Jan 2021 19:55:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43265 <at> debbugs.gnu.org, Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Sat, 23 Jan 2021 14:54:39 -0500
>>> All special forms get it (`if' is a special form), but macros (like
>>> `when') only gets it if we're in a funcall position:
>> Not sure why that is.  Seems like an accident.
> The special form bit, or the macro bit?  :-)

The fact that the two are treated differently.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Sun, 24 Jan 2021 19:59:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 43265 <at> debbugs.gnu.org, Mauro Aranda <maurooaranda <at> gmail.com>,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Sun, 24 Jan 2021 20:58:22 +0100
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>> All special forms get it (`if' is a special form), but macros (like
>>>> `when') only gets it if we're in a funcall position:
>>> Not sure why that is.  Seems like an accident.
>> The special form bit, or the macro bit?  :-)
>
> The fact that the two are treated differently.

The handling of the macros is "more correct".  Should we just remove the
special-casing of special forms?

It apparently was introduced by:

commit 9fdc166ee0ca212f7d5bf1cd9e1177932b0cd9aa
Author:     Tassilo Horn <tsdh <at> gnu.org>
AuthorDate: Mon Mar 16 10:25:14 2015 +0100

Before this, special forms and macros were handled in the same way, but
the commit message doesn't really explain why this was changed.

(Tassilo added to the CCs.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Sun, 24 Jan 2021 20:00:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 43265 <at> debbugs.gnu.org, Mauro Aranda <maurooaranda <at> gmail.com>,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Sun, 24 Jan 2021 20:59:24 +0100
(Oh, and I added some tests for the font locking here, including three
failing ones that illustrates the issues under discussion.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Sun, 24 Jan 2021 20:10:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: tsdh <at> gnu.org, 43265 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 maurooaranda <at> gmail.com
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Sun, 24 Jan 2021 22:09:01 +0200
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 24 Jan 2021 20:58:22 +0100
> Cc: 43265 <at> debbugs.gnu.org, Mauro Aranda <maurooaranda <at> gmail.com>,
>  Tassilo Horn <tsdh <at> gnu.org>
> 
> It apparently was introduced by:
> 
> commit 9fdc166ee0ca212f7d5bf1cd9e1177932b0cd9aa
> Author:     Tassilo Horn <tsdh <at> gnu.org>
> AuthorDate: Mon Mar 16 10:25:14 2015 +0100
> 
> Before this, special forms and macros were handled in the same way, but
> the commit message doesn't really explain why this was changed.

  https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00327.html

etc.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Sun, 24 Jan 2021 20:17:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tsdh <at> gnu.org, 43265 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 maurooaranda <at> gmail.com
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Sun, 24 Jan 2021 21:16:33 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Before this, special forms and macros were handled in the same way, but
>> the commit message doesn't really explain why this was changed.
>
>   https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg00327.html

Skimming that thread, I can't see any explanation for why we don't check
that special forms are in a function position, while we do that for
macros?

I.e.,

(setq a '(if a b))

is currently fontified incorrectly, while

(setq a '(when a b))

is fontified correctly.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Sun, 24 Jan 2021 21:27:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43265 <at> debbugs.gnu.org, Mauro Aranda <maurooaranda <at> gmail.com>,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Sun, 24 Jan 2021 16:25:58 -0500
> The handling of the macros is "more correct".  Should we just remove the
> special-casing of special forms?
>
> It apparently was introduced by:
>
> commit 9fdc166ee0ca212f7d5bf1cd9e1177932b0cd9aa

Looks like an accident: none of that change explains the difference
in treatment.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Sun, 24 Jan 2021 21:59:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "tsdh <at> gnu.org" <tsdh <at> gnu.org>,
 "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Sun, 24 Jan 2021 21:58:34 +0000
Oh boy - font-lock bikeshedding!

> Skimming that thread, I can't see any explanation for why we don't check
> that special forms are in a function position, while we do that for
> macros? I.e.,
> 
> (setq a '(if a b))   is currently fontified incorrectly, while
> (setq a '(when a b)) is fontified correctly.

Really?  Are you sure one is correct and the other not,
and that you have it the right way round? 

 (setq a '(setq b d))
 (setq a '(if a b))
 (setq a '(when a b))
 (setq a '(and a b))

Nowadays, all of those `setq's, the `if', and the `and'
are highlighted; poor-boy `when' isn't. :-(
___

But is it really "correct" to fontify _any_ of the names
in those quoted sexps as if they were being used with
their active meanings - as code?  In that context they're
just data - list elements.

It was Emacs 25 that started highlighting all of those
`setq's, and `and'.  Up through Emacs 24, `setq' and
`and' weren't highlighted anywhere - and both `if' and
`when' were highlighted (everywhere).

Emacs 25 made `when' a special case (unhighlighted), and
it made `setq' and `and' unspecial (highlighted).  That
new behavior is no more "correct" than what it replaced.

If any highlightings could be considered more correct
than others, I'd think a more correct one would _at
least_ not highlight function/macro/special-form names
when used as elements of a list (i.e. quoted) or as
plain-quoted atoms.

Consider:

 (defun foo (x y) 42) ; or (defmacro foo (x y) 42)
 (setq a '(foo a b))
 (setq a '(if a b))

`foo' in the quoted list isn't highlighted; `if' is.
Why?


In sum:

1. We're not very consistent (before or since Emacs 25).

2. The behavior's changed over time: sometimes to add
highlighting (`setq', `and'), sometimes to remove it
(`when').  Why?  Maybe (or maybe not) there were some
good reasons.  In any case, for a _user_ things are not
so clear.

3. IMO, it could make sense to not highlight such names
when they're not syntactically seen as being _used_ as
function/macro/special-form, but are instead seen as
data (e.g. quoted).

(When the use isn't obvious, pick a direction to err on,
and be relatively consistent about it.)

Now the question becomes, What constitutes "use" as a
function/macro/special-form?  Plain-quoting doesn't,
IMO; but what about #'?

How many angels fit on the head of a pin?  (Depends on
the angels and the pin.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 25 Jan 2021 06:38:02 GMT) Full text and rfc822 format available.

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

From: Tassilo Horn <tsdh <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>
Subject: Re: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Mon, 25 Jan 2021 07:30:31 +0100
>> Skimming that thread, I can't see any explanation for why we don't
>> check that special forms are in a function position, while we do that
>> for macros? I.e.,

Me neither, and as Stefan said, that's a change in that behavior has not
been intended by my patch.  It's intention was to highlight all macros
(except those declared with no-font-lock-keyword), no matter when they
are loaded.  E.g., when a new macro gets defined, it should also be
highlighted.

>> (setq a '(if a b))   is currently fontified incorrectly, while
>> (setq a '(when a b)) is fontified correctly.
>
> Really?  Are you sure one is correct and the other not,
> and that you have it the right way round? 
>
>  (setq a '(setq b d))
>  (setq a '(if a b))
>  (setq a '(when a b))
>  (setq a '(and a b))
>
> Nowadays, all of those `setq's, the `if', and the `and'
> are highlighted; poor-boy `when' isn't. :-(

All but `when' are special forms, so Lars is right that the distinction
is between special forms vs. macros.

> But is it really "correct" to fontify _any_ of the names
> in those quoted sexps as if they were being used with
> their active meanings - as code?  In that context they're
> just data - list elements.

Yeah, the special forms should probably not be highlighted here.

Bye,
Tassilo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 25 Jan 2021 06:40:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>,
 Drew Adams <drew.adams <at> oracle.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: Re: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Mon, 25 Jan 2021 07:39:29 +0100
Tassilo Horn <tsdh <at> gnu.org> writes:

> Me neither, and as Stefan said, that's a change in that behavior has not
> been intended by my patch.

Ah; thanks for confirming.  I'll change it so that special forms and
macros are handled the same way, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 25 Jan 2021 06:55:01 GMT) Full text and rfc822 format available.

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

From: Tassilo Horn <tsdh <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>,
 Drew Adams <drew.adams <at> oracle.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: Re: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Mon, 25 Jan 2021 07:46:46 +0100
> Tassilo Horn <tsdh <at> gnu.org> writes:
>
>> Me neither, and as Stefan said, that's a change in that behavior has
>> not been intended by my patch.
>
> Ah; thanks for confirming.  I'll change it so that special forms and
> macros are handled the same way, then.

Feel free to do so.  But I can also make an argument for the current
behavior: special forms are under our control and there aren't many, so
if they happen to be in a quoted form, it's likely that's actually code
eventually being run.  In contrast, the number of macros is
theoretically unbounded and naming is not restricted, so we can't say
anything about usage patterns of macro-named things in quoted lists.

Bye,
Tassilo




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 25 Jan 2021 14:01:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 Drew Adams <drew.adams <at> oracle.com>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>
Subject: Re: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Mon, 25 Jan 2021 08:59:59 -0500
> Feel free to do so.  But I can also make an argument for the current
> behavior: special forms are under our control and there aren't many, so
> if they happen to be in a quoted form, it's likely that's actually code
> eventually being run.

I don't see why that should be more likely for special forms than for
macros.  For many of them, which is which is largely an
arbitrary choice.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 25 Jan 2021 16:02:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>
Subject: RE: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Mon, 25 Jan 2021 16:01:23 +0000
> >> (setq a '(if a b))   is currently fontified incorrectly, while
> >> (setq a '(when a b)) is fontified correctly.
> >
> > Really?  Are you sure one is correct and the other not,
> > and that you have it the right way round?
> >
> >  (setq a '(setq b d))
> >  (setq a '(if a b))
> >  (setq a '(when a b))
> >  (setq a '(and a b))
> >
> > Nowadays, all of those `setq's, the `if', and the `and'
> > are highlighted; poor-boy `when' isn't. :-(
> 
> All but `when' are special forms, so Lars is right that the distinction
> is between special forms vs. macros.

That may be the distinction now, but the behavior has
changed over time.

The real question about that distinction should be
whether it's helpful/useful for users?  Typically
for Lisp whether a special form is implemented at
a lower-than-Lisp level or as a macro or in some
other way is only an implementation detail.

What's most helpful, for a user, in terms of
font-lock?  I'm guessing that the aim behind this
distinguishing special forms from macros by
highlighting is really aimed at distinguishing
user-defined macros from predefined macros.

To me, as one user, highlighting predefined
macros the same as special forms makes sense.
But so does highlighting all macros differently
from functions and special forms.  To me, it's
not so helpful to not highlight macros at all.

> > But is it really "correct" to fontify _any_ of the names
> > in those quoted sexps as if they were being used with
> > their active meanings - as code?  In that context they're
> > just data - list elements.
> 
> Yeah, the special forms should probably not be highlighted here.

That was my main point, yes.  To do that correctly
in the general case is maybe hard (when is something
"used" as a function/macro/special-form?).  But a
first approximation should be pretty easy and helpful.

Users can be helped by not highlighting such things
when quoted (e.g. in quoted lists).  Highlighting
them in such contexts is misleading.  That's the main
highlighting change I'd like to see made.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 25 Jan 2021 16:10:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Tassilo Horn <tsdh <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Mon, 25 Jan 2021 16:09:34 +0000
> >> Me neither, and as Stefan said, that's a change in that behavior has
> >> not been intended by my patch.
> >
> > Ah; thanks for confirming.  I'll change it so that special forms and
> > macros are handled the same way, then.
> 
> Feel free to do so.

Agreed.

> But I can also make an argument for the current
> behavior: special forms are under our control and there aren't many, so
> if they happen to be in a quoted form, it's likely that's actually code
> eventually being run.  In contrast, the number of macros is
> theoretically unbounded and naming is not restricted, so we can't say
> anything about usage patterns of macro-named things in quoted lists.

Highlighting macro names (when used as macros, but
not when just elements in a quoted list etc.) is
helpful, IMO.

For the reason you gave (macros are defined with
Lisp, and can be user-defined), my preference is
for a separate kind of highlighting for their
names - separate from special-form names and
function names.

Now, if people get excited about too much angry
fruit salad, the default face used for macro
names could just inherit from that for special
form names.  (But I'm against such "invisible"
face defaulting, in general.)
___

IMO, the priorities, in terms of importance
(help for users) are these.  (They might not be
the priorities for implementation, e.g. if #1
is thought to be hard to do or problematic.)

1. Stop highlighting names of functions, macros
and special forms when they are not being used
as such.  Don't highlight them when they are
just symbols in data (e.g. quote lists).

2. Other than #1, highlight function, macro,
and special-form names, each with a different
face.  (Or use the same face for special forms
and macros - but that's not my preference.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 25 Jan 2021 16:15:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Drew Adams <drew.adams <at> oracle.com>, Tassilo Horn <tsdh <at> gnu.org>, Lars
 Ingebrigtsen <larsi <at> gnus.org>
Cc: "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Mon, 25 Jan 2021 16:14:17 +0000
BTW: Would it be useful to take a poll about
the most useful behavior, or otherwise discuss
on emacs-devel what behavior to have?

I realize that this question is relatively
minor (~bike-shedding), but maybe users have
strong opinions or good ideas about it.

Just a question.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Mon, 25 Jan 2021 23:35:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "43265 <at> debbugs.gnu.org" <43265 <at> debbugs.gnu.org>,
 "maurooaranda <at> gmail.com" <maurooaranda <at> gmail.com>,
 Drew Adams <drew.adams <at> oracle.com>, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: [External] : bug#43265: 28.0.50; Inconsistent fontifying in
 elisp-mode
Date: Tue, 26 Jan 2021 00:34:42 +0100
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I don't see why that should be more likely for special forms than for
> macros.  For many of them, which is which is largely an
> arbitrary choice.

The only reason I see to handle special forms specially here is for
reasons of efficiency.  That is, we now do a lot more work for special
forms than we used to do, and special forms are a lot more common in
Emacs Lisp code than macros, so perhaps the performance regression isn't
worth it.

Emacs doesn't feel more sluggish to me than before making the change,
though, so I think the change was the right thing to do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Tue, 26 Jan 2021 00:20:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 43265 <at> debbugs.gnu.org
Subject: Re: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Tue, 26 Jan 2021 01:19:37 +0100
Mauro Aranda <maurooaranda <at> gmail.com> writes:

> (condition-case nil
>     (fail-badly)
>   (error (when foo t)))
>
> I don't see WHEN with font-lock-keyword-face.  However:
>
> (condition-case nil
>     (fail-badly)
>   (error (if foo t)))
>
> IF has font-lock-keyword-face.

I forgot to mention in this bug report (since we started talking about
other things here) that this bit has been fixed.

So I'm closing this bug report.  Opening a new one about
`edebug-form-spec' when doing highlights may be appropriate, if that's
something that somebody wants to work on.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 28.1, send any further explanations to 43265 <at> debbugs.gnu.org and Mauro Aranda <maurooaranda <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 26 Jan 2021 00:20:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#43265; Package emacs. (Tue, 26 Jan 2021 00:28:02 GMT) Full text and rfc822 format available.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43265 <at> debbugs.gnu.org
Subject: Re: bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Mon, 25 Jan 2021 21:27:38 -0300
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> (condition-case nil
>>     (fail-badly)
>>   (error (when foo t)))
>>
>> I don't see WHEN with font-lock-keyword-face.  However:
>>
>> (condition-case nil
>>     (fail-badly)
>>   (error (if foo t)))
>>
>> IF has font-lock-keyword-face.
>
> I forgot to mention in this bug report (since we started talking about
> other things here) that this bit has been fixed.
>

Thanks!




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 23 Feb 2021 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 33 days ago.

Previous Next


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