From: Tassilo Horn <tsdh@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: "maurooaranda@gmail.com" <maurooaranda@gmail.com>,
Lars Ingebrigtsen <larsi@gnus.org>,
"43265@debbugs.gnu.org" <43265@debbugs.gnu.org>,
"monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>
Subject: bug#43265: [External] : bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode
Date: Mon, 25 Jan 2021 07:30:31 +0100 [thread overview]
Message-ID: <87pn1t7c9g.fsf@gnu.org> (raw)
In-Reply-To: <SA2PR10MB447488AD516666F6F38C9862F3BE9@SA2PR10MB4474.namprd10.prod.outlook.com>
>> 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
next prev parent reply other threads:[~2021-01-25 6:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 20:05 bug#43265: 28.0.50; Inconsistent fontifying in elisp-mode Mauro Aranda
2021-01-22 19:32 ` Lars Ingebrigtsen
2021-01-22 20:11 ` Mauro Aranda
2021-01-22 22:32 ` Stefan Monnier
2021-01-23 18:42 ` Lars Ingebrigtsen
2021-01-23 19:54 ` Stefan Monnier
2021-01-24 19:58 ` Lars Ingebrigtsen
2021-01-24 19:59 ` Lars Ingebrigtsen
2021-01-24 20:09 ` Eli Zaretskii
2021-01-24 20:16 ` Lars Ingebrigtsen
2021-01-24 21:58 ` bug#43265: [External] : " Drew Adams
2021-01-25 6:30 ` Tassilo Horn [this message]
2021-01-25 6:39 ` Lars Ingebrigtsen
2021-01-25 6:46 ` Tassilo Horn
2021-01-25 13:59 ` Stefan Monnier
2021-01-25 23:34 ` Lars Ingebrigtsen
2021-01-25 16:09 ` Drew Adams
2021-01-25 16:14 ` Drew Adams
2021-01-25 16:01 ` Drew Adams
2021-01-24 21:25 ` Stefan Monnier
2021-01-26 0:19 ` Lars Ingebrigtsen
2021-01-26 0:27 ` Mauro Aranda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pn1t7c9g.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=43265@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=larsi@gnus.org \
--cc=maurooaranda@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.