unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists
@ 2018-10-16 17:49 Garreau, Alexandre
  2018-10-16 18:35 ` Alan Mackenzie
  2018-10-16 21:23 ` Stefan Monnier
  0 siblings, 2 replies; 6+ messages in thread
From: Garreau, Alexandre @ 2018-10-16 17:49 UTC (permalink / raw)
  To: emacs-devel

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?



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists
  2018-10-16 17:49 emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists Garreau, Alexandre
@ 2018-10-16 18:35 ` Alan Mackenzie
  2018-10-16 19:22   ` Garreau, Alexandre
  2018-10-16 20:12   ` Garreau, Alexandre
  2018-10-16 21:23 ` Stefan Monnier
  1 sibling, 2 replies; 6+ messages in thread
From: Alan Mackenzie @ 2018-10-16 18:35 UTC (permalink / raw)
  To: Garreau, Alexandre; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists
  2018-10-16 18:35 ` Alan Mackenzie
@ 2018-10-16 19:22   ` Garreau, Alexandre
  2018-10-16 20:10     ` Alan Mackenzie
  2018-10-16 20:12   ` Garreau, Alexandre
  1 sibling, 1 reply; 6+ messages in thread
From: Garreau, Alexandre @ 2018-10-16 19:22 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists
  2018-10-16 19:22   ` Garreau, Alexandre
@ 2018-10-16 20:10     ` Alan Mackenzie
  0 siblings, 0 replies; 6+ messages in thread
From: Alan Mackenzie @ 2018-10-16 20:10 UTC (permalink / raw)
  To: Garreau, Alexandre; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists
  2018-10-16 18:35 ` Alan Mackenzie
  2018-10-16 19:22   ` Garreau, Alexandre
@ 2018-10-16 20:12   ` Garreau, Alexandre
  1 sibling, 0 replies; 6+ messages in thread
From: Garreau, Alexandre @ 2018-10-16 20:12 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists
  2018-10-16 17:49 emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists Garreau, Alexandre
  2018-10-16 18:35 ` Alan Mackenzie
@ 2018-10-16 21:23 ` Stefan Monnier
  1 sibling, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2018-10-16 21:23 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-10-16 21:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-10-16 17:49 emacs-lisp-mode highlights incorrectly defmacros/defuns’ arglists Garreau, Alexandre
2018-10-16 18:35 ` Alan Mackenzie
2018-10-16 19:22   ` Garreau, Alexandre
2018-10-16 20:10     ` Alan Mackenzie
2018-10-16 20:12   ` Garreau, Alexandre
2018-10-16 21:23 ` Stefan Monnier

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