[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alan Mackenzie
Subject: Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists
Date: Tue, 16 Oct 2018 20:10:09 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]