bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#51661: 29.0.50; What is "interactive Lisp closure"?


From: Eli Zaretskii
Subject: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 16:06:33 +0200

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 51661@debbugs.gnu.org
> Date: Sun, 07 Nov 2021 14:55:54 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To reproduce:
> >
> >   emacs -Q
> >   C-h f emoji-insert RET
> >
> > This says:
> >
> >   emoji-insert is an autoloaded interactive Lisp closure in ‘emoji.el’.
> >
> > Other commands still say "interactive compiled Lisp function", at
> > least the few I tried did.
> 
> I think that's because your emoji.el isn't byte-compiled?  Hm...  mine's
> not byte-compiled either?  Do we have to add some incantation somewhere
> to get newly-added .el files to be byte-compiled?

No.  But emoji.el says this:

      (insert ";; Local" " Variables:
  ;; coding: utf-8
  ;; version-control: never
  ;; no-byte-compile: t
  ;; no-update-autoloads: t
  ;; End:

  (provide 'emoji-labels)

and that trips the 'compile-main' target in lisp/Makefile to think
this file should not be byte-compiled.

> > Is this the same "closure"?
> 
> Yes.
> 
> > What is special about this command that we say "closure" there?  Do we
> > have to confuse users by showing that in the Help buffers?
> 
> C-h f will say that about all uncompiled functions that use lexical
> binding, I think?  So there's nothing special about it.  (If it didn't
> use lexical binding it'd say "lambda" instead of "closure", I guess.)
> 
> I have no opinion on whether this distinction (lambda/closure) is
> meaningful to expose to the user in `C-h f'.

I think we should replace "closure" by "function" in the Help buffer.
There's no need to show this to users.





reply via email to

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