bug#12761: cl-lib.el functions do not get font-locked like cl.el ones

bug#12761: cl-lib.el functions do not get font-locked like cl.el ones

[Glenn Morris]

Package: emacs
Version: 24.2.50
Severity: minor

In current trunk:

emacs -Q -l cl

(letf ...)
(cl-letf ...)

`letf' gets font-lock-keyword-face, `cl-letf' does not get fontified.

bug#12761: cl-lib.el functions do not get font-locked like cl.el ones

[Stefan Monnier]

> `letf' gets font-lock-keyword-face, `cl-letf' does not get fontified.

I'm not sure which of the two is a bug, to tell you the truth.


        Stefan

bug#12761: cl-lib.el functions do not get font-locked like cl.el ones

[Glenn Morris]

Stefan Monnier wrote:

>> `letf' gets font-lock-keyword-face, `cl-letf' does not get fontified.
>
> I'm not sure which of the two is a bug, to tell you the truth.

I guess the bug was ever font-locking things from cl.el that are not in
Common Lisp. So maybe that special treatment (lexical-let, letf, etc)
should be removed, to make everyone equally miserable.

bug#12761: cl-lib.el functions do not get font-locked like cl.el ones

[Stefan Monnier]

>>> `letf' gets font-lock-keyword-face, `cl-letf' does not get fontified.
>> I'm not sure which of the two is a bug, to tell you the truth.
> I guess the bug was ever font-locking things from cl.el that are not in
> Common Lisp.

And to the extent that cl.el's "namespace uncleanliness" was enough to
ostracize it, font-locking the elements which are in Common-Lisp (but
not in core Elisp) was also a mistake.

> So maybe that special treatment (lexical-let, letf, etc)
> should be removed, to make everyone equally miserable.

Right.  But then the "cl-*" versions could be fine choices (tho I'd
much rather not hard code those things in the font-lock rules.
Couldn't we build those dynamically by loading cl-lib.el, then going
through the obarray, keeping all macros whose name starts with "cl-" but
not "cl--"?).


        Stefan

bug#12761: cl-lib.el functions do not get font-locked like cl.el ones

[Christopher Schmidt]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> So maybe that special treatment (lexical-let, letf, etc)
>> should be removed, to make everyone equally miserable.
>
> Right.  But then the "cl-*" versions could be fine choices (tho I'd
> much rather not hard code those things in the font-lock rules.
> Couldn't we build those dynamically by loading cl-lib.el, then going
> through the obarray, keeping all macros whose name starts with "cl-"
> but not "cl--"?).

+1.

I think it might be a good idea to remove CL font lock support in
emacs-lisp-mode and its deviates by default.  A function that adds
keyword highlighting on the fly could be added, though.

    (require 'cl-lib)

    (defun add-cl-font-lock-keywords ()
      (font-lock-add-keywords
       'emacs-lisp-mode
       (eval-when-compile
         (cl-loop
          for s being the symbols
          for n = (symbol-name s)
          when (and (string-match-p "^cl-[^-]" n)
                    (condition-case nil
                        (eq (car (symbol-function s)) 'macro)
                      (error)))
          collect (list (concat "(\\(?:[ \t]*\\)\\<\\("
                                (regexp-quote n)
                                "\\)\\>")
                        1
                        font-lock-keyword-face)
          end))))

An user just needs to put (add-cl-font-lock-keywords) in his init.el in
case he really wants CL font lock support.

I am just brainstorming here.  This does not take care of
lisp-interaction-mode, *scratch*, etc.

        Christopher

bug#12761: bug #12761 - please do it

[Drew Adams]

Whatever way you choose to implement it, please do font-lock
`cl-*' and `*' Common-Lisp stuff - at least all of the defining
forms (e.g., `cl-defstruct').  This should have been done as part
of the task of adding such things to Emacs.

Please also font-lock (and add to Imenu) `gv-define-setter' &
compagnie.

ALL defining forms that are part of distributed Emacs source
code should be font-locked by default.  Users should not have
to do anything to get this highlighting.

(They could conceivably be given a means to turn font-locking
off for some defining forms, but that is not something that I
would propose.)

bug#12761: bug #12761 - please do it

[Stefan Monnier]

> Please also font-lock (and add to Imenu) `gv-define-setter' &
> compagnie.

Actually, gv setters and expanders should normally be added via
(declare (gv-setter ...)) or (declare (gv-expander ...)), so they don't
need any special handling in Imenu or font-lock.


        Stefan

bug#12761: bug #12761 - please do it

[Drew Adams]

> > Please also font-lock (and add to Imenu) `gv-define-setter' &
> > compagnie.
> 
> Actually, gv setters and expanders should normally be added via
> (declare (gv-setter ...)) or (declare (gv-expander ...)), so they don't
> need any special handling in Imenu or font-lock.

Good to hear. But I don't see that, not yet at least. Not in this build:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-07 on ODIEONE
Bzr revision: 113750 lekktu@gmail.com-20130808011911-0jzpc9xuncegg6x9
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

Visit frameset.el and search for `(gv-define-setter frameset-prop'.
Do you see `gv-define-setter' highlighted?  Do you see its first arg
highlighted?

The name of its first arg is in Imenu as a function, but perhaps that
is only because there is also a `(defun frameset-prop)'.

Personally, I care more about the font-locking, FWIW.

bug#12761: bug #12761 - please do it

[Stefan Monnier]

>> > Please also font-lock (and add to Imenu) `gv-define-setter' &
>> > compagnie.
>> 
>> Actually, gv setters and expanders should normally be added via
>> (declare (gv-setter ...)) or (declare (gv-expander ...)), so they don't
>> need any special handling in Imenu or font-lock.

> Good to hear. But I don't see that, not yet at least. Not in this build:
[...]
> Visit frameset.el and search for `(gv-define-setter frameset-prop'.
> Do you see `gv-define-setter' highlighted?  Do you see its first arg
> highlighted?

You misread me.  I'm saying that frameset.el should not call
gv-define-setter and should instead use (declare (gv-setter ...)).


        Stefan

bug#12761: bug #12761 - please do it

[Drew Adams]

> >> > Please also font-lock (and add to Imenu) `gv-define-setter' &
> >> > compagnie.
> >>
> >> Actually, gv setters and expanders should normally be added via
> >> (declare (gv-setter ...)) or (declare (gv-expander ...)), so they don't
> >> need any special handling in Imenu or font-lock.
> 
> > Good to hear. But I don't see that, not yet at least. Not in this build:
> [...]
> > Visit frameset.el and search for `(gv-define-setter frameset-prop'.
> > Do you see `gv-define-setter' highlighted?  Do you see its first arg
> > highlighted?
> 
> You misread me.  I'm saying that frameset.el should not call
> gv-define-setter and should instead use (declare (gv-setter ...)).

I see.  Yes, I misunderstood.

bug#12761: bug #12761 - please do it

[Juanma Barranquero]

On Wed, Aug 14, 2013 at 4:33 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> You misread me.  I'm saying that frameset.el should not call
> gv-define-setter and should instead use (declare (gv-setter ...)).

I have that already in my local copy of frameset.el (which includes a
few other changes that I want to push to the repo).

But I have refrained of pushing that specific change because (declare
(gv-*...)) isn't documented. I just filed a bug report about that.

   J