* bug#15219: Emacs Lisp mode and Lisp mode font-locking
@ 2013-08-30 9:32 Bozhidar Batsov
2013-08-30 12:45 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Bozhidar Batsov @ 2013-08-30 9:32 UTC (permalink / raw)
To: 15219
[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]
I've noticed something odd about the font-locking in Emacs Lisp mode and Lisp mode - keyword args are highlighted using the font-lock-builtin-face and constructs like &optional are highlighted using font-lock-type-face. I guess this was was done way back and hasn't been updated in a while, but I think it might a good idea to revise this. Pretty sure those font faces are intended for different usage. I think it would be great if all Emacs programming modes used the built-in font-lock faces consistently, so that the meaning of certain faces doesn't change from mode to mode. I guess that the two modes might also start using the font-lock-built-in face to highlight their core functions (like car, cdr, mapcar, mapc, etc) - as Clojure mode does. Personally I feel that uses of the keyword face fo
r things that are not special forms (like the when macro) should be replaced with uses of the built-in face.
I've posted this to devel a while back (http://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00592.html) and Michael Heerdegen suggested reporting it as a bug as well.
--
Cheers,
Bozhidar
[-- Attachment #2: Type: text/html, Size: 1498 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#15219: Emacs Lisp mode and Lisp mode font-locking
2013-08-30 9:32 bug#15219: Emacs Lisp mode and Lisp mode font-locking Bozhidar Batsov
@ 2013-08-30 12:45 ` Stefan Monnier
2013-08-30 13:23 ` Bozhidar Batsov
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2013-08-30 12:45 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: 15219
> I've noticed something odd about the font-locking in Emacs Lisp mode and
> Lisp mode - keyword args are highlighted using the font-lock-builtin-face
> and constructs like &optional are highlighted using
> font-lock-type-face. I guess this was was done way back and hasn't been
> updated in a while, but I think it might a good idea to revise this. Pretty
> sure those font faces are intended for different usage. I think it would be
> great if all Emacs programming modes used the built-in font-lock faces
> consistently, so that the meaning of certain faces doesn't change from mode
> to mode. I guess that the two modes might also start using the
> font-lock-built-in face to highlight their core functions (like car, cdr,
> mapcar, mapc, etc) - as Clojure mode does. Personally I feel that uses of
> the keyword face for things that are not special forms (like the when macro)
> should be replaced with uses of the built-in face.
Which things are special forms and which things are macros is
somewhat arbitrary. The important thing to know about them is that
they're not functions, so their arguments may not be evaluated in the
usual way.
Also macros are used to introduce new syntactic constructs: in normal
programming languages, something like `when' would be highlighted as
a `keyword', not as a `builtin'.
I'm not completely sure what the `builtin' is used for, usually.
What information is it meant to provide? I mean, do you consider
`mapcar' "builtin" because it's fast? Because it's implemented in C?
Because it's predefined (no need for any kind of autoloading/require)?
Is `car' builtin because "if you didn't have it, you'd have to invent
it" (IOW can't be implemented in Elisp)?
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#15219: Emacs Lisp mode and Lisp mode font-locking
2013-08-30 12:45 ` Stefan Monnier
@ 2013-08-30 13:23 ` Bozhidar Batsov
2019-10-30 13:30 ` Lars Ingebrigtsen
0 siblings, 1 reply; 4+ messages in thread
From: Bozhidar Batsov @ 2013-08-30 13:23 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 15219
[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]
On Friday, August 30, 2013 at 3:45 PM, Stefan Monnier wrote:
> > I've noticed something odd about the font-locking in Emacs Lisp mode and
> > Lisp mode - keyword args are highlighted using the font-lock-builtin-face
> > and constructs like &optional are highlighted using
> > font-lock-type-face. I guess this was was done way back and hasn't been
> > updated in a while, but I think it might a good idea to revise this. Pretty
> > sure those font faces are intended for different usage. I think it would be
> > great if all Emacs programming modes used the built-in font-lock faces
> > consistently, so that the meaning of certain faces doesn't change from mode
> > to mode. I guess that the two modes might also start using the
> > font-lock-built-in face to highlight their core functions (like car, cdr,
> > mapcar, mapc, etc) - as Clojure mode does. Personally I feel that uses of
> > the keyword face for things that are not special forms (like the when macro)
> > should be replaced with uses of the built-in face.
> >
>
>
> Which things are special forms and which things are macros is
> somewhat arbitrary. The important thing to know about them is that
> they're not functions, so their arguments may not be evaluated in the
> usual way.
>
>
Fair point. I guess it makes sense to some extend to consider some macros to be "keywords".
> Also macros are used to introduce new syntactic constructs: in normal
> programming languages, something like `when' would be highlighted as
> a `keyword', not as a `builtin'.
>
> I'm not completely sure what the `builtin' is used for, usually.
> What information is it meant to provide?
>
>
Generally the idea behind fontifying built-ins (AFAIK) is to remind programmers that something is part of the core of the language and it'd be unwise to redefine or shadow it. For instance in Clojure mode all methods from the clojure.core namespace are font-locked with the built-in face.
> I mean, do you consider
> `mapcar' "builtin" because it's fast? Because it's implemented in C?
> Because it's predefined (no need for any kind of autoloading/require)?
> Is `car' builtin because "if you didn't have it, you'd have to invent
> it" (IOW can't be implemented in Elisp)?
>
Normally built-in functions would be those that came with the standard library of the language and are pretty generic in nature. I guess in Emacs Lisp that would be functions like mapcar, mapc, vector, car, cdr - the building blocks on which everything else rests upon. I guess there are not that much of those and they haven't changed much in a long while. And as the Emacs manual itself states "font-lock-builtin-face is for the names of built-in functions".
>
>
> Stefan
Anyways, I'd be happy to get just a fix for the keywords and &optional (and related) faces, since those are definitely off.
[-- Attachment #2: Type: text/html, Size: 4353 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#15219: Emacs Lisp mode and Lisp mode font-locking
2013-08-30 13:23 ` Bozhidar Batsov
@ 2019-10-30 13:30 ` Lars Ingebrigtsen
0 siblings, 0 replies; 4+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-30 13:30 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Stefan Monnier, 15219
Bozhidar Batsov <bozhidar.batsov@gmail.com> writes:
> Anyways, I'd be happy to get just a fix for the keywords and &optional (and
> related) faces, since those are definitely off.
The complaint is that :foobar below uses font-lock-builtin-face and
&optional uses font-lock-type-face in emacs-lisp-mode.
(defun foo (bar &optional zot)
(list :foobar bar))
This is defined in lisp-cl-font-lock-keywords in lisp-mode.el, and I
agree that separate faces should probably be used for those -- keywords
aren't builtins and &optional isn't a type.
:keywords are constants, I guess, but we use font-lock-constant-face for
catch/throw and the like, and I don't think we have anything that
vaguely makes sense for &optional.
Would adding new faces for these make sense?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-10-30 13:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-30 9:32 bug#15219: Emacs Lisp mode and Lisp mode font-locking Bozhidar Batsov
2013-08-30 12:45 ` Stefan Monnier
2013-08-30 13:23 ` Bozhidar Batsov
2019-10-30 13:30 ` Lars Ingebrigtsen
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).