unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Tassilo Horn <tsdh@gnu.org>
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 16:01:23 +0000	[thread overview]
Message-ID: <SA2PR10MB44749C285296CE5569C6FE12F3BD9@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87pn1t7c9g.fsf@gnu.org>

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





  parent reply	other threads:[~2021-01-25 16:01 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
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 [this message]
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SA2PR10MB44749C285296CE5569C6FE12F3BD9@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=43265@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=maurooaranda@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=tsdh@gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).