GNU bug report logs - #51661
29.0.50; What is "interactive Lisp closure"?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51661 in the body.
You can then email your comments to 51661 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 15:36:50 +0200

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.

What is "an autoloaded interactive Lisp closure"?  There's no mention
of it in the Emacs user manual, and the Emacs Lisp Reference manual
says this about closures:

     A closure is a function that also carries a record of the lexical
  environment that existed when the function was defined.  When it is
  invoked, any lexical variable references within its definition use the
  retained lexical environment.  In all other respects, closures behave
  much like ordinary functions; in particular, they can be called in the
  same way as ordinary functions.

Is this the same "closure"?  What is special about this command that
we say "closure" there?  Do we have to confuse users by showing that
in the Help buffers?

In GNU Emacs 29.0.50 (build 137, i686-pc-mingw32)
 of 2021-11-07 built on HOME-C4E4A596F7
Repository revision: a05f6bb6718a6ba2617d367e665d6f658a518448
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS WEBP
XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: ELisp/l

Minor modes in effect:
  bug-reference-prog-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config
gnus-util rmail rmail-loaddefs auth-source password-cache json map
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils vc-git diff-mode easy-mmode vc-dispatcher
bug-reference shortdoc text-property-search eieio-opt speedbar ezimage
dframe find-func emoji pcase derived transient cl-seq format-spec
edmacro kmacro eieio eieio-core cl-macs eieio-loaddefs cl-extra seq gv
subr-x byte-opt bytecomp byte-compile cconv thingatpt help-fns
radix-tree help-mode cl-loaddefs cl-lib iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads w32notify
w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 89759 6808)
 (symbols 48 9892 1)
 (strings 16 31319 2890)
 (string-bytes 1 870273)
 (vectors 16 18283)
 (vector-slots 8 232402 11964)
 (floats 8 78 46)
 (intervals 40 554 168)
 (buffers 888 13))

Message #8 received at 51661 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51661 <at> debbugs.gnu.org
Subject: Re: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 14:55:54 +0100

Eli Zaretskii <eliz <at> 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?

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 51661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51661 <at> debbugs.gnu.org
Subject: Re: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 16:06:33 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 51661 <at> debbugs.gnu.org
> Date: Sun, 07 Nov 2021 14:55:54 +0100
> 
> Eli Zaretskii <eliz <at> 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.

Message #14 received at 51661 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51661 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 15:10:22 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

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

D'oh.  I thought my obfuscation there was sufficient.  I'll get fixing.

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

Let's see...  it's this code?  I'm guessing Stefan M wrote this, so I'm
adding him to the CCs.

(defun help-fns-function-description-header (function)
  "Print a line describing FUNCTION to `standard-output'."
  (pcase-let* ((`(,_real-function ,def ,aliased ,real-def)
                (help-fns--analyze-function function))
               (file-name (find-lisp-object-file-name function (if aliased 'defun
                                                                 def)))
               (beg (if (and (or (byte-code-function-p def)
                                 (keymapp def)
                                 (memq (car-safe def) '(macro lambda closure)))
                             (stringp file-name)
                             (help-fns--autoloaded-p function file-name))
                        (concat
                         "an autoloaded " (if (commandp def)
                                              "interactive "))
                      (if (commandp def) "an interactive " "a "))))

I don't really have an opinion.  I agree that "closure"/"lambda" here is
probably more information than most users have asked for, but on the
other hand, it's a reality, so how much of the details should we hide?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 51661 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51661 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 15:18:59 +0100

On Nov 07 2021, Lars Ingebrigtsen wrote:

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

Remove ";; no-byte-compile: t" from the file.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #20 received at 51661 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51661 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 18:28:47 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> 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.
>
> D'oh.  I thought my obfuscation there was sufficient.  I'll get fixing.

you could add a ^L after the function (or better near eof) to prevent
Emacs from parsing that string as a file local variable.  It might be
more clear than further obfuscation (as in 42fd5f2789).

Best, Arash

Message #23 received at 51661 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Arash Esbati <arash <at> gnu.org>
Cc: 51661 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 22:01:16 +0100

Arash Esbati <arash <at> gnu.org> writes:

> you could add a ^L after the function (or better near eof) to prevent
> Emacs from parsing that string as a file local variable.

I tried that now, but it didn't seem to help.

We really need a general "this thing here shouldn't be interpreted by
any of the things that look for this stuff" mechanism.  But I'm not sure
what that would look like.

(with-uninterpreted-text
  (insert ";; Local Variables:
;; coding: utf-8
;; version-control: never"))

or something?  The code that's looking for these things are pretty
simple, though, and would have to be made more complicated, which is a
downside.

Stefan M's solution (use \s instead of space) is probably the best.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #26 received at 51661 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51661 <at> debbugs.gnu.org, Arash Esbati <arash <at> gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Sun, 07 Nov 2021 17:33:27 -0500

> (with-uninterpreted-text
>   (insert ";; Local Variables:
> ;; coding: utf-8
> ;; version-control: never"))

In the current case, the parsing of the `;; no-byte-compile: t` is not
done by Emacs but by the Makefile (via some grep, IIRC).


        Stefan

Message #31 received at 51661 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51661 <at> debbugs.gnu.org
Subject: Re: bug#51661: 29.0.50; What is "interactive Lisp closure"?
Date: Tue, 20 Sep 2022 14:07:36 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

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

[...]

> Is this the same "closure"?  What is special about this command that
> we say "closure" there?  Do we have to confuse users by showing that
> in the Help buffers?

I think so -- in this case it pointed to a bug in our build (the
emoji.el file wasn't compiled), so I think this is working like it
should, and I'm therefore closing this bug report.

(It says

---
emoji-insert is an autoloaded interactive byte-compiled Lisp function
in emoji.el.
---

now.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.