bug#59714: 30.0.50; (void-function cl-letf)

bug#59714: 30.0.50; (void-function cl-letf)

[Manuel Uberti via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

this is the problem:

- emacs -Q
- Evaluate: (cl-letf (((default-value 'process-environment) nil)))
- You see the following error:

Debugger entered--Lisp error: (void-function cl-letf)
   (cl-letf (((default-value 'process-environment) nil)))
   (progn (cl-letf (((default-value 'process-environment) nil))))
   eval((progn (cl-letf (((default-value 'process-environment) nil)))) t)
   elisp--eval-last-sexp(nil)
   eval-last-sexp(nil)
   funcall-interactively(eval-last-sexp nil)
   call-interactively(eval-last-sexp nil nil)
   command-execute(eval-last-sexp)

- Evaluate again: (cl-letf (((default-value 'process-environment) nil)))

The error is not shown any more.

For reference, I discovered this while using buffer-env:
https://github.com/astoff/buffer-env/issues/15.

Augusto Stoffel provided the small recipe, I was seeing the message 
"‘((default-value 'process-environment) process-environment)’ is a 
malformed function" as I wrote in the above mentioned ticket.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
  3.24.33, cairo version 1.16.0) of 2022-11-29 built on baruch
Repository revision: 7939184f8e0370e7a3397d492812c6d202c2a193
Repository branch: master
System Description: Ubuntu 22.04.1 LTS

Configured using:
  'configure --with-native-compilation --with-pgtk'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS XIM GTK3 ZLIB

Important settings:
   value of $LC_MESSAGES: en_GB.UTF-8
   value of $LC_MONETARY: it_IT.UTF-8
   value of $LC_NUMERIC: it_IT.UTF-8
   value of $LC_TIME: it_IT.UTF-8
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   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
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search 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 help-fns
radix-tree cl-print byte-opt debug backtrace find-func cl-loaddefs comp
comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode
bytecomp byte-compile cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win pgtk-dnd 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 91808 7241)
  (symbols 48 7534 0)
  (strings 32 25267 3098)
  (string-bytes 1 792684)
  (vectors 16 19382)
  (vector-slots 8 302629 15510)
  (floats 8 46 24)
  (intervals 56 404 0)
  (buffers 984 12))

-- 
Manuel Uberti
https://manueluberti.eu

bug#59714: 30.0.50; (void-function cl-letf)

[Eli Zaretskii]

> Date: Wed, 30 Nov 2022 07:45:51 +0100
> From:  Manuel Uberti via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> this is the problem:
> 
> - emacs -Q
> - Evaluate: (cl-letf (((default-value 'process-environment) nil)))
> - You see the following error:
> 
> Debugger entered--Lisp error: (void-function cl-letf)
>    (cl-letf (((default-value 'process-environment) nil)))
>    (progn (cl-letf (((default-value 'process-environment) nil))))
>    eval((progn (cl-letf (((default-value 'process-environment) nil)))) t)
>    elisp--eval-last-sexp(nil)
>    eval-last-sexp(nil)
>    funcall-interactively(eval-last-sexp nil)
>    call-interactively(eval-last-sexp nil nil)
>    command-execute(eval-last-sexp)
> 
> - Evaluate again: (cl-letf (((default-value 'process-environment) nil)))
> 
> The error is not shown any more.

Why is this a problem?  Before you evaluate the offending expression,
(featurep 'cl-lib) yields nil, after that it yields t (because Emacs needed
to load that package).  I don't see what is wrong here.

bug#59714: 30.0.50; (void-function cl-letf)

[Augusto Stoffel]

FTR, I observe this behavior as well, and what confuses me is that,
according to `C-h f', `cl-letf' is an autoloaded macro.  I'd expect this
to be as good as being preloaded.

bug#59714: 30.0.50; (void-function cl-letf)

[Manuel Uberti via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Why is this a problem?  Before you evaluate the offending
 > expression, (featurep 'cl-lib) yields nil, after that it
 > yields t (because Emacs needed to load that package).  I
 > don't see what is wrong here.

As Augusto said, I was expecting the macro to be autoloaded and thus 
with no need to require `cl-lib` explicitly to use it.

However, if requiring `cl-lib` is the right thing to do this ticket can 
be closed.

-- 
Manuel Uberti
https://manueluberti.eu

bug#59714: 30.0.50; (void-function cl-letf)

[Eli Zaretskii]

> Date: Wed, 30 Nov 2022 17:06:37 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, arstoffel@gmail.com
> From: Manuel Uberti <manuel.uberti@inventati.org>
> 
>  > Why is this a problem?  Before you evaluate the offending
>  > expression, (featurep 'cl-lib) yields nil, after that it
>  > yields t (because Emacs needed to load that package).  I
>  > don't see what is wrong here.
> 
> As Augusto said, I was expecting the macro to be autoloaded and thus 
> with no need to require `cl-lib` explicitly to use it.

Thanks, but that was not clear from your original report, in which you
presented two invocations without any explanations.  As I now understand,
the first invocation, which signaled an error, and the fact that cl-letf is
supposed to be autoloaded (which you didn't mention at all) should have been
enough to explain the issue.

Please try in the future to post the relevant details when you report an
issue, to facilitate faster handling and to avoid unnecessary confusion and
email exchange.

TIA

bug#59714: 30.0.50; (void-function cl-letf)

[Manuel Uberti via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 30/11/22 17:57, Eli Zaretskii wrote:
> Thanks, but that was not clear from your original report, in which you
> presented two invocations without any explanations.  As I now understand,
> the first invocation, which signaled an error, and the fact that cl-letf is
> supposed to be autoloaded (which you didn't mention at all) should have been
> enough to explain the issue.
> 
> Please try in the future to post the relevant details when you report an
> issue, to facilitate faster handling and to avoid unnecessary confusion and
> email exchange.

I see. Sorry for not being clear before. Since now the details are 
clearer, is the bug report still relevant?

-- 
Manuel Uberti
https://manueluberti.eu

bug#59714: 30.0.50; (void-function cl-letf)

[Eli Zaretskii]

> Date: Wed, 30 Nov 2022 07:45:51 +0100
> From:  Manuel Uberti via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> - emacs -Q
> - Evaluate: (cl-letf (((default-value 'process-environment) nil)))
> - You see the following error:
> 
> Debugger entered--Lisp error: (void-function cl-letf)
>    (cl-letf (((default-value 'process-environment) nil)))
>    (progn (cl-letf (((default-value 'process-environment) nil))))
>    eval((progn (cl-letf (((default-value 'process-environment) nil)))) t)
>    elisp--eval-last-sexp(nil)
>    eval-last-sexp(nil)
>    funcall-interactively(eval-last-sexp nil)
>    call-interactively(eval-last-sexp nil nil)
>    command-execute(eval-last-sexp)

I don't understand how autoloading macros or functions from cl-lib could
work as the above expects.  The autoload forms of these functions and macros
are written to cl-loaddefs.el, but the only file that loads cl-loaddefs.el
is cl-lib itself.  So you must (require 'cl-lib) to be able to use cl-letf.

Stefan, did I miss something?

bug#59714: 30.0.50; (void-function cl-letf)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> So you must (require 'cl-lib) to be able to use cl-letf.

Definitely.
The `cl-loaddefs.el` is used to autoload things *after* that step, so
that loading `cl-lib` doesn't need to eagerly load all the files that
comprise `cl-lib`.


        Stefan

bug#59714: 30.0.50; (void-function cl-letf)

[Augusto Stoffel]

On Wed, 30 Nov 2022 at 14:45, Stefan Monnier wrote:

>> So you must (require 'cl-lib) to be able to use cl-letf.
>
> Definitely.
> The `cl-loaddefs.el` is used to autoload things *after* that step, so
> that loading `cl-lib` doesn't need to eagerly load all the files that
> comprise `cl-lib`.

Okay, that explains many things...  FWIW, it has always confused me that
C-h f cl-letf RET says

    cl-letf is an autoloaded Lisp macro in ‘cl-macs.el’.

From a user perspective, the autoloadedness claim is definitely less
than 50% true.

bug#59714: 30.0.50; (void-function cl-letf)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Okay, that explains many things...  FWIW, it has always confused me that
> C-h f cl-letf RET says
>
>     cl-letf is an autoloaded Lisp macro in ‘cl-macs.el’.
>
> From a user perspective, the autoloadedness claim is definitely less
> than 50% true.

It's true in the sense that you don't need to (require 'cl-macs),
[ and indeed you shouldn't (require 'cl-macs) ]

Whether that's more or less than 50% ....


        Stefan

bug#59714: 30.0.50; (void-function cl-letf)

[Manuel Uberti via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Thanks everyone for the clarification. I see no problem requiring `cl-lib'.

This ticket can be closed.

-- 
Manuel Uberti
https://manueluberti.eu

bug#59714: 30.0.50; (void-function cl-letf)

[Eli Zaretskii]

> Date: Thu, 1 Dec 2022 06:26:50 +0100
> From:  Manuel Uberti via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Thanks everyone for the clarification. I see no problem requiring `cl-lib'.
> 
> This ticket can be closed.

Thanks, done.