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

Previous Next

Full log

View this message in rfc822 format

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: bug#43265: [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

Previous Next

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