emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists

emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists

[Garreau, Alexandre]

At least *someone* must have *seen* this:
#+BEGIN_SRC elisp
(defmacro unless (cond &rest body)
  "If COND yields nil, do BODY, else return nil.
When COND yields nil, eval BODY forms sequentially and return
value of last one, or nil if there are none.

\(fn COND BODY...)"
  (declare (indent 1) (debug t))
  (cons 'if (cons cond (cons nil body))))
#+END_SRC

“cond” is highlighted in blue, while since defmacro (as well as defun,
which present the same issue) is itself a macro, and the meaning of its
arglist is known and fixed in lisp (a list of symbols, whose the first
isn’t particularly meant to be called), why is cond highlighted just as
if the arglist was a real form to be evaluated, while we know it’s not?

Wouldn’t there be a way to turn off these highlightings in such places
of known old and fixed macro calls?

Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists

[Alan Mackenzie]

Hello, Alexandre.

On Tue, Oct 16, 2018 at 19:49:53 +0200, Garreau, Alexandre wrote:
> At least *someone* must have *seen* this:
> #+BEGIN_SRC elisp
> (defmacro unless (cond &rest body)
>   "If COND yields nil, do BODY, else return nil.
> When COND yields nil, eval BODY forms sequentially and return
> value of last one, or nil if there are none.

> \(fn COND BODY...)"
>   (declare (indent 1) (debug t))
>   (cons 'if (cons cond (cons nil body))))
> #+END_SRC

> “cond” is highlighted in blue, while since defmacro (as well as defun,
> which present the same issue) is itself a macro, and the meaning of its
> arglist is known and fixed in lisp (a list of symbols, whose the first
> isn’t particularly meant to be called), why is cond highlighted just as
> if the arglist was a real form to be evaluated, while we know it’s not?

You surely are conscious of the fact that `cond' is a special form?  To
use it as an argument name is asking for trouble, surely.

The font locking in emacs-lisp-mode appears not to be too sophisticated.
But it is fast.

> Wouldn’t there be a way to turn off these highlightings in such places
> of known old and fixed macro calls?

There might well be, but it would slow fontification down, somewhat.  I
suspect that changing "cond" to something less contentious will get the
result you want.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists

[Garreau, Alexandre]

On 2018-10-16 at 18:35, Alan Mackenzie wrote:
> On Tue, Oct 16, 2018 at 19:49:53 +0200, Garreau, Alexandre wrote:
>> At least *someone* must have *seen* this:
>> #+BEGIN_SRC elisp
>> (defmacro unless (cond &rest body)
>>   "If COND yields nil, do BODY, else return nil.
>> When COND yields nil, eval BODY forms sequentially and return
>> value of last one, or nil if there are none.
>
>> \(fn COND BODY...)"
>>   (declare (indent 1) (debug t))
>>   (cons 'if (cons cond (cons nil body))))
>> #+END_SRC
>
> You surely are conscious of the fact that `cond' is a special form?

I am, yet from the time it’s used as either a variable, or a macro arg,
normally that shouldn’t cause any issue… otherwise what’s the point of a
lisp-2, with 2 whole different namespaces?

> To use it as an argument name is asking for trouble, surely.

Still Emacs seems to use it extensively to mean “form evaluating to a
boolean” (different from “test” which is a function returning a
boolean), this nicely and understandably have the same as the most
primitive, old and handy special form taking those as arguments.

This exemple was an excerpt of subr.el.  And I noticed there that there
were many others.  As a probably quite old convention, this must trace
back to long ago so it must be disseminated all around emacs’ source
code.

Do you have any so better name to suggest for replacing the symbol
“cond” used as a variable everywhere in emacs’ source code?  because
otherwise I feel like it’s the fontification who’s wrong here.

> The font locking in emacs-lisp-mode appears not to be too
> sophisticated.  But it is fast.
>
>> Wouldn’t there be a way to turn off these highlightings in such
>> places of known old and fixed macro calls?
>
> There might well be, but it would slow fontification down, somewhat.
> I suspect that changing "cond" to something less contentious will get
> the result you want.

That much? Emacs source code using “cond” extensively, I’ve thought this
would be a must-have feature.  This always bugged me and I just re-saw
it so I thought about talking about it.

Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists

[Alan Mackenzie]

On Tue, Oct 16, 2018 at 21:22:25 +0200, Garreau, Alexandre wrote:
> On 2018-10-16 at 18:35, Alan Mackenzie wrote:
> > On Tue, Oct 16, 2018 at 19:49:53 +0200, Garreau, Alexandre wrote:
> >> At least *someone* must have *seen* this:
> >> #+BEGIN_SRC elisp
> >> (defmacro unless (cond &rest body)
> >>   "If COND yields nil, do BODY, else return nil.
> >> When COND yields nil, eval BODY forms sequentially and return
> >> value of last one, or nil if there are none.

> >> \(fn COND BODY...)"
> >>   (declare (indent 1) (debug t))
> >>   (cons 'if (cons cond (cons nil body))))
> >> #+END_SRC

> > You surely are conscious of the fact that `cond' is a special form?

> I am, yet from the time it’s used as either a variable, or a macro arg,
> normally that shouldn’t cause any issue… otherwise what’s the point of a
> lisp-2, with 2 whole different namespaces?

> > To use it as an argument name is asking for trouble, surely.

> Still Emacs seems to use it extensively to mean “form evaluating to a
> boolean” (different from “test” which is a function returning a
> boolean), this nicely and understandably have the same as the most
> primitive, old and handy special form taking those as arguments.

Apologies.  `cond' is indeed used as the name of a first argument
elsewhere, but relatively seldom.  I found six occurrences with a grep.

> This exemple was an excerpt of subr.el.  And I noticed there that there
> were many others.  As a probably quite old convention, this must trace
> back to long ago so it must be disseminated all around emacs’ source
> code.

Maybe it is, maybe it's not.  As I said, it's not common in Emacs's own
source code, having `cond' as a first argument.  Perhaps it occurs more
often in let, let* binding clauses (where it's more difficult to find
with grep).

> Do you have any so better name to suggest for replacing the symbol
> “cond” used as a variable everywhere in emacs’ source code? ....

Not really.  I've just looked up "condition" in a thesaurus, and perhaps
`stip' (for stipulation), or ...  No, there's really not much to suggest.
:-(

> .... because otherwise I feel like it’s the fontification who’s wrong
> here.

It is wrong, yes.  But is it wrong enough to justify the effort it would
take to fix it?

If you're experienced in emacs lisp, or wanting to become so, this could
be a good project for you to undertake.  You care about this a fair bit,
I don't, really, and I suspect most other Emacs contributors don't,
either.  Help would be available in this list.

> > The font locking in emacs-lisp-mode appears not to be too
> > sophisticated.  But it is fast.

> >> Wouldn’t there be a way to turn off these highlightings in such
> >> places of known old and fixed macro calls?

> > There might well be, but it would slow fontification down, somewhat.
> > I suspect that changing "cond" to something less contentious will get
> > the result you want.

> That much? Emacs source code using “cond” extensively, I’ve thought this
> would be a must-have feature.  This always bugged me and I just re-saw
> it so I thought about talking about it.

The expert in this area is Stefan Monnier.  Maybe he'll answer you
directly.  But, as I say, if you decided to tackle the problem yourself,
you'd get a positive reaction from people, here.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists

[Garreau, Alexandre]

On 2018-10-16 at 18:35, Alan Mackenzie wrote:
> The font locking in emacs-lisp-mode appears not to be too sophisticated.
> But it is fast.
>
>> Wouldn’t there be a way to turn off these highlightings in such places
>> of known old and fixed macro calls?
>
> There might well be, but it would slow fontification down, somewhat.  I
> suspect that changing "cond" to something less contentious will get the
> result you want.

I just noticed the following (thanks to my persistent procrastination to
(of?) learn paredit, and some lucky unbalanced parenthesis): this issue
does not arise for `when', when it is bound as a variable inside a
`let', but it does for cond, nevertheless: the issue does also arise for
`when' as an argument of a defun.

I guess the reason of this oddity is macros and special forms are
treated differently, yet I can’t understand trivially why defuns args
and let args behaves differently as both are symbol to be bound…

But since `let' seems, at least for macros, to disable fontification,
“disabling fontification in some place” must not slow down that much
things I guess.

Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists

[Stefan Monnier]

> At least *someone* must have *seen* this:
> #+BEGIN_SRC elisp
> (defmacro unless (cond &rest body)
>   "If COND yields nil, do BODY, else return nil.
> When COND yields nil, eval BODY forms sequentially and return
> value of last one, or nil if there are none.
>
> \(fn COND BODY...)"
>   (declare (indent 1) (debug t))
>   (cons 'if (cons cond (cons nil body))))
> #+END_SRC
>
> “cond” is highlighted in blue, while since defmacro (as well as defun,
> which present the same issue) is itself a macro, and the meaning of its
> arglist is known and fixed in lisp (a list of symbols, whose the first
> isn’t particularly meant to be called), why is cond highlighted just as
> if the arglist was a real form to be evaluated, while we know it’s not?

Because you haven't yet submitted the patch which will fix this.


        Stefan


PS: I've been annoyed by this in the case of arglist that start with
`function` rather than with `cond`, but never enough to start trying to
fix it.  Note there's another similar situation I encounter every once
in a while, which is:

   (cond
    (cond blabla)
    blibli)