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