bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Mauro Aranda]

[-- Attachment #1: Type: text/plain, Size: 3340 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3718 bytes --]

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Lars Ingebrigtsen]

Mauro Aranda <maurooaranda@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

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Mauro Aranda]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Mauro Aranda <maurooaranda@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.

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Stefan Monnier]

> 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

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Stefan Monnier <monnier@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:


[-- Attachment #2: Type: image/png, Size: 6013 bytes --]

[-- Attachment #3: Type: text/plain, Size: 702 bytes --]


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

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Stefan Monnier]

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

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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@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

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Lars Ingebrigtsen]

(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

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 24 Jan 2021 20:58:22 +0100
> Cc: 43265@debbugs.gnu.org, Mauro Aranda <maurooaranda@gmail.com>,
>  Tassilo Horn <tsdh@gnu.org>
> 
> It apparently was introduced by:
> 
> commit 9fdc166ee0ca212f7d5bf1cd9e1177932b0cd9aa
> Author:     Tassilo Horn <tsdh@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.

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Drew Adams]

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

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Tassilo Horn]

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

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@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

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Tassilo Horn]

> Tassilo Horn <tsdh@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

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Stefan Monnier]

> 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

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Drew Adams]

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

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Drew Adams]

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.

bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Drew Adams]

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

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Stefan Monnier]

> 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

bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Lars Ingebrigtsen]

Mauro Aranda <maurooaranda@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#43265: 28.0.50; Inconsistent fontifying in elisp-mode

[Mauro Aranda]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Mauro Aranda <maurooaranda@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!