GNU bug report logs - #58396
29.0.50; Optimization failure for add-to-list

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 58396 in the body.
You can then email your comments to 58396 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: German Pacenza <germanp82 <at> hotmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Optimization failure for add-to-list
Date: Sun, 09 Oct 2022 13:20:17 -0300

emacs -Q
(setq tab-always-indent 'complete)
(add-to-list pac ;; without the quote. Press TAB after the 'c'

Result:
Completion succeeds but I get the following in the echo area:
Warning: Optimization failure for add-to-list: Handler: add-to-list--anon-cmacro
(wrong-number-of-arguments #<subr add-to-list--anon-cmacro> 2)

With toggle-debug-on-error:

  Debugger entered--Lisp error: (wrong-number-of-arguments #<subr add-to-list--anon-cmacro> 2)
  add-to-list--anon-cmacro((add-to-list elisp--witness--lisp) elisp--witness--lisp)
  apply(add-to-list--anon-cmacro (add-to-list elisp--witness--lisp) elisp--witness--lisp)
  macroexp--compiler-macro(add-to-list--anon-cmacro (add-to-list elisp--witness--lisp))
  macroexp--expand-all((add-to-list elisp--witness--lisp))
  macroexpand-all((add-to-list elisp--witness--lisp))
  elisp--local-variables()
  #f(compiled-function (string) #<bytecode -0x5fa893eaaf40814>)(#("pac" 0 3 (fontified t)))
  #f(compiled-function (string pred action) #<bytecode -0x14ed6e54e1050bfd>)(#("pac" 0 3 (fontified t)) nil nil)
  try-completion(#("pac" 0 3 (fontified t)) #f(compiled-function (string pred action) #<bytecode -0x14ed6e54e1050bfd>) nil)
  #f(compiled-function (table) #<bytecode 0x163689b2ac80c2c2>)(#f(compiled-function (string pred action) #<bytecode -0x14ed6e54e1050bfd>))
  mapcar(#f(compiled-function (table) #<bytecode 0x163689b2ac80c2c2>) (#f(compiled-function (string pred action) #<bytecode -0x14ed6e54e1050bfd>) #f(compiled-function (&rest args2) #<bytecode -0x8019f0ea8564a64>)))
  #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>)(#("pac" 0 3 (fontified t)) nil nil)
  completion-basic-try-completion(#("pac" 0 3 (fontified t)) #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>) nil 3)
  #f(compiled-function (style) #<bytecode 0x178204c4fc0cae41>)(basic)
  completion--some(#f(compiled-function (style) #<bytecode 0x178204c4fc0cae41>) (basic partial-completion emacs22))
  completion--nth-completion(1 #("pac" 0 3 (fontified t)) #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>) nil 3 (metadata))
  completion-try-completion(#("pac" 0 3 (fontified t)) #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>) nil 3 (metadata))
  completion--do-completion(#<marker at 194 in *scratch*> 197)
  completion--in-region-1(#<marker at 194 in *scratch*> 197)
  #f(compiled-function (start end collection predicate) #<bytecode 0x3790782fa7b3d68>)(#<marker at 194 in *scratch*> 197 #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>) nil)
  apply(#f(compiled-function (start end collection predicate) #<bytecode 0x3790782fa7b3d68>) (#<marker at 194 in *scratch*> 197 #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>) nil))
  #f(compiled-function (funs global args) #<bytecode -0xf600c7e743d322>)(nil nil (#<marker at 194 in *scratch*> 197 #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>) nil))
  completion--in-region(#<marker at 194 in *scratch*> 197 #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>) nil)
  completion-in-region(#<marker at 194 in *scratch*> 197 #f(compiled-function (string pred action) #<bytecode -0x18f4dd5c4c465f31>) nil)
  completion-at-point()
  indent-for-tab-command(nil)
  funcall-interactively(indent-for-tab-command nil)
  command-execute(indent-for-tab-command)



In GNU Emacs 29.0.50 (build 15, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.17.6) of 2022-10-08 built on KRONOS
Repository revision: 84945e86be6b8dc8237983de901eb677bee3ae8b
Repository branch: master
System Description: Manjaro Linux

Configured using:
 'configure --without-modules --without-libotf --without-m17n-flt
 --without-gconf --with-pgtk --with-sound=no --without-gpm
 --with-native-compilation --without-gsettings --without-libsystemd
 --without-sqlite3 --without-xim --without-compress-install
 --prefix=/home/german/.local/emacs'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG JSON LCMS2
LIBXML2 NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP THREADS
TIFF TOOLKIT_SCROLL_BARS WEBP XIM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: es_AR.UTF-8
  value of $LC_NUMERIC: es_AR.UTF-8
  value of $LC_TIME: es_AR.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  savehist-mode: t
  electric-pair-mode: t
  vertico-multiform-mode: t
  vertico-mode: t
  popper-mode: t
  minibuffer-depth-indicate-mode: t
  delete-selection-mode: t
  straight-use-package-mode: t
  straight-package-neutering-mode: t
  straight-live-modifications-mode: t
  global-so-long-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
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/german/.emacs.d/straight/build/transient/transient hides /home/german/.local/emacs/share/emacs/29.0.50/lisp/transient

Features:
(shadow sort mail-extr emacsbug smerge-mode diff face-remap mm-archive
mule-util edmacro kmacro notmuch notmuch-tree notmuch-jump notmuch-hello
wid-edit notmuch-show notmuch-print notmuch-crypto notmuch-mua
notmuch-message notmuch-draft notmuch-maildir-fcc notmuch-address
notmuch-company notmuch-parser format-spec notmuch-wash diff-mode coolj
goto-addr thingatpt icalendar diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs notmuch-tag crm notmuch-lib notmuch-version notmuch-compat
hl-line message sendmail yank-media dired dired-loaddefs rfc822 mml
mailabbrev mail-utils gmm-utils mailheader mm-view mml-smime mml-sec epa
derived epg rfc6068 epg-config gnus-util text-property-search time-date
smime password-cache gnutls puny dig mm-decode mm-bodies mm-encode
mailcap mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
savehist comp comp-cstr warnings icons rx elec-pair vertico-flat
vertico-grid vertico-multiform pcase vertico helpful-autoloads
elisp-refs-autoloads f-autoloads s-autoloads popper popper-autoloads
magit-autoloads magit-section-autoloads git-commit-autoloads
with-editor-autoloads transient-autoloads dash-autoloads
agitate-autoloads elfeed-autoloads vertico-autoloads embark-autoloads
consult-autoloads compat-autoloads mb-depth orderless-autoloads info
delsel xah-fly-keys easy-mmode xah-fly-keys-autoloads
rainbow-mode-autoloads g3r-dark-theme straight-autoloads cl-seq cl-extra
help-mode straight subr-x cl-macs gv bytecomp byte-compile cconv so-long
cl-loaddefs cl-lib rmc iso-transl tooltip 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 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 font-render-setting cairo gtk pgtk lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 149476 70469)
 (symbols 48 12413 2)
 (strings 32 37772 11828)
 (string-bytes 1 1409276)
 (vectors 16 22922)
 (vector-slots 8 456664 164114)
 (floats 8 64 237)
 (intervals 56 354 80)
 (buffers 1000 11))

-- 
German Pacenza

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: German Pacenza <germanp82 <at> hotmail.com>
Cc: 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Mon, 10 Oct 2022 10:25:58 +0200

German Pacenza <germanp82 <at> hotmail.com> writes:

> emacs -Q
> (setq tab-always-indent 'complete)
> (add-to-list pac ;; without the quote. Press TAB after the 'c'
>
> Result:
> Completion succeeds but I get the following in the echo area:
> Warning: Optimization failure for add-to-list: Handler: add-to-list--anon-cmacro
> (wrong-number-of-arguments #<subr add-to-list--anon-cmacro> 2)
>
> With toggle-debug-on-error:
>
>   Debugger entered--Lisp error: (wrong-number-of-arguments #<subr add-to-list--anon-cmacro> 2)

This seems like it's the same problem as reported in bug#58148 (so I'm
merging the two reports).

(And now I'm able to reproduce the problem.)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: German Pacenza <germanp82 <at> hotmail.com>
Cc: 58396 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Mon, 10 Oct 2022 10:34:15 +0200

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

>> emacs -Q
>> (setq tab-always-indent 'complete)
>> (add-to-list pac ;; without the quote. Press TAB after the 'c'
>>
>> Result:
>> Completion succeeds but I get the following in the echo area:
>> Warning: Optimization failure for add-to-list: Handler:
>> add-to-list--anon-cmacro
>> (wrong-number-of-arguments #<subr add-to-list--anon-cmacro> 2)
>>
>> With toggle-debug-on-error:
>>
>>   Debugger entered--Lisp error: (wrong-number-of-arguments #<subr
>> add-to-list--anon-cmacro> 2)
>
> This seems like it's the same problem as reported in bug#58148 (so I'm
> merging the two reports).

I don't quite understand the calling sequence how we end up here; I've
added Stefan to the CCs -- he wrote `elisp--local-variables' back in
2014:

Debugger entered--Lisp error: (wrong-number-of-arguments ((t) (form keymap key definition) (ignore keymap key definition) (keymap--compile-check key) form) 2)
  keymap-set--anon-cmacro((keymap-set elisp--witness--lisp) elisp--witness--lisp)
  apply(keymap-set--anon-cmacro (keymap-set elisp--witness--lisp) elisp--witness--lisp)
  macroexp--compiler-macro(keymap-set--anon-cmacro (keymap-set elisp--witness--lisp))
  #f(compiled-function (form func) #<bytecode -0x18f8a3887af7552>)(((keymap-set elisp--witness--lisp)) keymap-set)
  macroexp--expand-all((keymap-set elisp--witness--lisp))
  macroexpand-all((keymap-set elisp--witness--lisp))
  elisp--local-variables()

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Mon, 10 Oct 2022 10:59:04 -0400

Lars Ingebrigtsen [2022-10-10 10:34:15] wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>>> emacs -Q
>>> (setq tab-always-indent 'complete)
>>> (add-to-list pac ;; without the quote. Press TAB after the 'c'
>>>
>>> Result:
>>> Completion succeeds but I get the following in the echo area:
>>> Warning: Optimization failure for add-to-list: Handler:
>>> add-to-list--anon-cmacro
>>> (wrong-number-of-arguments #<subr add-to-list--anon-cmacro> 2)
>>>
>>> With toggle-debug-on-error:
>>>
>>>   Debugger entered--Lisp error: (wrong-number-of-arguments #<subr
>>> add-to-list--anon-cmacro> 2)
>>
>> This seems like it's the same problem as reported in bug#58148 (so I'm
>> merging the two reports).
>
> I don't quite understand the calling sequence how we end up here; I've
> added Stefan to the CCs -- he wrote `elisp--local-variables' back in
> 2014:
>
> Debugger entered--Lisp error: (wrong-number-of-arguments ((t) (form keymap
> key definition) (ignore keymap key definition) (keymap--compile-check key)
> form) 2)
>   keymap-set--anon-cmacro((keymap-set elisp--witness--lisp) elisp--witness--lisp)
>   apply(keymap-set--anon-cmacro (keymap-set elisp--witness--lisp) elisp--witness--lisp)
>   macroexp--compiler-macro(keymap-set--anon-cmacro (keymap-set elisp--witness--lisp))
>   #f(compiled-function (form func)
> #<bytecode -0x18f8a3887af7552>)(((keymap-set elisp--witness--lisp))
> keymap-set)
>   macroexp--expand-all((keymap-set elisp--witness--lisp))
>   macroexpand-all((keymap-set elisp--witness--lisp))
>   elisp--local-variables()

Hmm... we should arrange for this `macroexpand-all` call not to emit any
messages (and it should arguably also skip the compiler-macros) since we
know it'll often be used on code that's not (yet) valid.

I'm not sure which part you don't understand above, so I'll only explain
the general situation: to allow completion of local variable names, we
analyze the surrounding code, but in order to do that without having to
write ad-hoc code that knows about all the macros out there that can
introduce new vars, we take the "surrounding code" and macroexpand the
hell out of it so that we can then traverse the result looking only for
`let/let*/lambda/condition-case`.


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Tue, 11 Oct 2022 02:28:40 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I'm not sure which part you don't understand above, so I'll only explain
> the general situation: to allow completion of local variable names, we
> analyze the surrounding code, but in order to do that without having to
> write ad-hoc code that knows about all the macros out there that can
> introduce new vars, we take the "surrounding code" and macroexpand the
> hell out of it so that we can then traverse the result looking only for
> `let/let*/lambda/condition-case`.

But why is it calling add-to-list--anon-cmacro with the wrong number of
parameters?

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>
Cc: German Pacenza <germanp82 <at> hotmail.com>,
 "58396 <at> debbugs.gnu.org" <58396 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#58396: 29.0.50; Optimization failure for
 add-to-list
Date: Tue, 11 Oct 2022 01:53:09 +0000

> > But why is it calling add-to-list--anon-cmacro with the wrong number of parameters?

Perhaps the name should be

add-to-list--anon-cmacro-with-the-wrong-number-of-parameters

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Mon, 10 Oct 2022 23:46:46 -0400

Lars Ingebrigtsen [2022-10-11 02:28:40] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I'm not sure which part you don't understand above, so I'll only explain
>> the general situation: to allow completion of local variable names, we
>> analyze the surrounding code, but in order to do that without having to
>> write ad-hoc code that knows about all the macros out there that can
>> introduce new vars, we take the "surrounding code" and macroexpand the
>> hell out of it so that we can then traverse the result looking only for
>> `let/let*/lambda/condition-case`.
>
> But why is it calling add-to-list--anon-cmacro with the wrong number of
> parameters?

Because that's the sort of error you can get if you try to macro-expand
code that's syntactically invalid.  E.g. try to compile a file with

    (add-to-list x)

and you should see a similar error.  For `elisp--local-variables`,
syntactically invalid code is the normal case (more or less) both
because it's used when we're in the middle of writing the code, and also
because of how it works (it takes the code from beginning-of-defun up
to point and throws away whatever follows, just adding enough closing
parens that the resutling string is `read`able).


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Tue, 11 Oct 2022 20:27:42 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Because that's the sort of error you can get if you try to macro-expand
> code that's syntactically invalid.  E.g. try to compile a file with
>
>     (add-to-list x)
>
> and you should see a similar error.  For `elisp--local-variables`,
> syntactically invalid code is the normal case (more or less) both
> because it's used when we're in the middle of writing the code, and also
> because of how it works (it takes the code from beginning-of-defun up
> to point and throws away whatever follows, just adding enough closing
> parens that the resutling string is `read`able).

I see.

Shouldn't this function then be suppressing all errors while it's doing
this exploratory macro-expansion stuff?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Tue, 11 Oct 2022 15:13:25 -0400

Lars Ingebrigtsen [2022-10-11 20:27:42] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Because that's the sort of error you can get if you try to macro-expand
>> code that's syntactically invalid.  E.g. try to compile a file with
>>
>>     (add-to-list x)
>>
>> and you should see a similar error.  For `elisp--local-variables`,
>> syntactically invalid code is the normal case (more or less) both
>> because it's used when we're in the middle of writing the code, and also
>> because of how it works (it takes the code from beginning-of-defun up
>> to point and throws away whatever follows, just adding enough closing
>> parens that the resutling string is `read`able).
>
> I see.
>
> Shouldn't this function then be suppressing all errors while it's doing
> this exploratory macro-expansion stuff?

Yes (plus silence the messages plus avoid compiler macros).


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Wed, 12 Oct 2022 12:54:36 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Yes (plus silence the messages plus avoid compiler macros).

Any chance that...  someone...  will do that?  😇

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Tue, 26 Sep 2023 22:30:47 +0200

[Message part 1 (text/plain, inline)]

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

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> Yes (plus silence the messages plus avoid compiler macros).
>
> Any chance that...  someone...  will do that?  😇
>

Hit this issue today.  How about the attached patch, which seems to fix
it?  I hope I understood Stefan's directions correctly.

BTW, bug#60081 could also be merged with this one.

[0001-Silence-macro-expansion-during-completion-at-point.patch (text/x-diff, inline)]

From 83387466cfb7fe859b227fb00148ee7f6cd288a5 Mon Sep 17 00:00:00 2001
From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Date: Tue, 26 Sep 2023 22:26:15 +0200
Subject: [PATCH] Silence macro expansion during completion-at-point

* lisp/progmodes/elisp-mode.el (elisp--local-variables): Silence
messages.  Avoid compiler macros.  Suppress all errors during macro
expansion.  (Bug#58396)
---
 lisp/progmodes/elisp-mode.el | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index bd3916ce108..809df64a536 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -445,11 +445,23 @@ elisp--local-variables
                                    (condition-case nil
                                        (apply expander form args)
                                      (error form))))
+             (macroexp--c-m-advice (lambda (_handler form) form))
+             ;; Avoid any macro expansion errors when attempting
+             ;; completion at point (bug#58148).  As Stefan suggested
+             ;; there: Silence messages [1], avoid compiler macros
+             ;; [2], and suppress all errors [3].
              (sexp
               (unwind-protect
-                  (let ((warning-minimum-log-level :emergency))
+                  (let ((inhibit-message t)     ;[1]
+                        (warning-minimum-log-level :emergency))
                     (advice-add 'macroexpand :around macroexpand-advice)
-                    (macroexpand-all sexp))
+                    (advice-add 'macroexp--compiler-macro :override
+                                macroexp--c-m-advice) ;[2]
+                    (condition-case nil
+                        (macroexpand-all sexp)
+                      (t sexp)))                ;[3]
+                (advice-remove 'macroexp--compiler-macro
+                               macroexp--c-m-advice)
                 (advice-remove 'macroexpand macroexpand-advice)))
              (vars (elisp--local-variables-1 nil sexp)))
         (delq nil
-- 
2.30.2

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Tue, 26 Sep 2023 17:32:26 -0400

> From 83387466cfb7fe859b227fb00148ee7f6cd288a5 Mon Sep 17 00:00:00 2001
> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Date: Tue, 26 Sep 2023 22:26:15 +0200
> Subject: [PATCH] Silence macro expansion during completion-at-point
>
> * lisp/progmodes/elisp-mode.el (elisp--local-variables): Silence
> messages.  Avoid compiler macros.  Suppress all errors during macro
> expansion.  (Bug#58396)

Thanks.  I think it would be cleaner to introduce a variable in
`macroexp.el` which `elisp--local-variables` can bind and which
`macroexp.el` can check so we avoid (ab)using advice.


        Stefan

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Tue, 26 Sep 2023 23:48:06 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> From 83387466cfb7fe859b227fb00148ee7f6cd288a5 Mon Sep 17 00:00:00 2001
>> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
>> Date: Tue, 26 Sep 2023 22:26:15 +0200
>> Subject: [PATCH] Silence macro expansion during completion-at-point
>>
>> * lisp/progmodes/elisp-mode.el (elisp--local-variables): Silence
>> messages.  Avoid compiler macros.  Suppress all errors during macro
>> expansion.  (Bug#58396)
>
> Thanks.  I think it would be cleaner to introduce a variable in
> `macroexp.el` which `elisp--local-variables` can bind and which
> `macroexp.el` can check so we avoid (ab)using advice.

What about naming it `macroexp-inhibit-compiler-macros´?

I also wanted to ask whether to extend that approach to the other advice
installed in `elisp--local-variables´ but then noticed that
`macroexpand´ is actually a built-in.  Which would be a bit over my head
...

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Tue, 26 Sep 2023 18:06:53 -0400

> What about naming it `macroexp-inhibit-compiler-macros´?

Perfect!

> I also wanted to ask whether to extend that approach to the other advice
> installed in `elisp--local-variables´

That would be nice, but...

> but then noticed that `macroexpand´ is actually a built-in.

`elisp--local-variables´ doesn't use that built-in any more, it uses
`macroexpand-1` instead, which is implemented in `macroexp.el` :-)

But the problem is that the advice wraps the call within
a `condition-case` and that's inconvenient to do in a way which
doesn't interfere too much with "normal use" (e.g. doesn't hide/catch
errors when we don't want to, and doesn't impose too much of
a performance cost either).

Then again, maybe I'm worrying about nothing.


        Stefan

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Sat, 30 Sep 2023 12:39:57 +0200

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I also wanted to ask whether to extend that approach to the other advice
>> installed in `elisp--local-variables´
>
> That would be nice, but...
>
>> but then noticed that `macroexpand´ is actually a built-in.
>
> `elisp--local-variables´ doesn't use that built-in any more, it uses
> `macroexpand-1` instead, which is implemented in `macroexp.el` :-)
>
> But the problem is that the advice wraps the call within
> a `condition-case` and that's inconvenient to do in a way which
> doesn't interfere too much with "normal use" (e.g. doesn't hide/catch
> errors when we don't want to, and doesn't impose too much of
> a performance cost either).

Agreed.

Anyway, here are two patches: One for Emacs 29 and one for master.

The patch for Emacs 29:

- does not contain the rather non-local change for avoiding compiler
  macros.  But it fixes this bug, anyway, by just ignoring all errors
  during the `macroexpand-all' call.

- contains a "don't merge to master" maker in the commit message.

What do you think?

[0001-29-Silence-macro-expansion-during-completion-at-point.patch (text/x-diff, inline)]

From cc663ccb14f3fae361733fe9742d7c7d07274d54 Mon Sep 17 00:00:00 2001
From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Date: Tue, 26 Sep 2023 22:26:15 +0200
Subject: [PATCH] Silence macro expansion during completion-at-point

* lisp/progmodes/elisp-mode.el (elisp--local-variables): Silence
messages.  Suppress all errors during macro expansion.  (Bug#58396)

Do not merge to master.
---
 lisp/progmodes/elisp-mode.el | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index bd3916ce108..bc01058ff3c 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -445,11 +445,19 @@ elisp--local-variables
                                    (condition-case nil
                                        (apply expander form args)
                                      (error form))))
+             ;; Avoid any macro expansion errors when attempting
+             ;; completion at point (bug#58148).  As Stefan suggested
+             ;; there: Silence messages [1] and suppress all errors
+             ;; [3].  (Not avoiding compiler macros in the current
+             ;; release branch, though.)
              (sexp
               (unwind-protect
-                  (let ((warning-minimum-log-level :emergency))
+                  (let ((inhibit-message t)     ;[1]
+                        (warning-minimum-log-level :emergency))
                     (advice-add 'macroexpand :around macroexpand-advice)
-                    (macroexpand-all sexp))
+                    (condition-case nil         ;[3]
+                        (macroexpand-all sexp)
+                      (t sexp)))
                 (advice-remove 'macroexpand macroexpand-advice)))
              (vars (elisp--local-variables-1 nil sexp)))
         (delq nil
-- 
2.30.2

[0001-30-Silence-macro-expansion-during-completion-at-point.patch (text/x-diff, inline)]

From feb9906cece4a1fbce6417e9225a937aa7e8c830 Mon Sep 17 00:00:00 2001
From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Date: Fri, 29 Sep 2023 22:04:43 +0200
Subject: [PATCH] Silence macro expansion during completion-at-point

* lisp/emacs-lisp/macroexp.el (macroexp-inhibit-compiler-macros): Add
variable.
(macroexp--compiler-macro): Inspect that new variable and, if it is
non-nil, return the input form unchanged.
* lisp/progmodes/elisp-mode.el (elisp--local-variables): Silence
messages.  Avoid compiler macros.  Suppress all errors during macro
expansion.  (Bug#58396)
---
 lisp/emacs-lisp/macroexp.el  | 20 ++++++++++++++------
 lisp/progmodes/elisp-mode.el | 12 ++++++++++--
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el
index 3ef924a5c73..6eb670d6dc1 100644
--- a/lisp/emacs-lisp/macroexp.el
+++ b/lisp/emacs-lisp/macroexp.el
@@ -105,13 +105,21 @@ macroexp--all-clauses
 	(macroexp--all-forms clause skip)
       clause)))
 
+(defvar macroexp-inhibit-compiler-macros nil
+  "Inhibit application of compiler macros if non-nil.")
+
 (defun macroexp--compiler-macro (handler form)
-  (condition-case-unless-debug err
-      (apply handler form (cdr form))
-    (error
-     (message "Warning: Optimization failure for %S: Handler: %S\n%S"
-              (car form) handler err)
-     form)))
+  "Apply compiler macro HANDLER to FORM and return the result.
+Unless `macroexp-inhibit-compiler-macros' is non-nil, in which
+case return FORM unchanged."
+  (if macroexp-inhibit-compiler-macros
+      form
+    (condition-case-unless-debug err
+        (apply handler form (cdr form))
+      (error
+       (message "Warning: Optimization failure for %S: Handler: %S\n%S"
+                (car form) handler err)
+       form))))
 
 (defun macroexp--funcall-if-compiled (_form)
   "Pseudo function used internally by macroexp to delay warnings.
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 664299df288..434b493ed55 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -458,11 +458,19 @@ elisp--local-variables
                     (apply expander form args)
                   ((debug error)
                    (message "Ignoring macroexpansion error: %S" err) form))))
+             ;; Avoid any macro expansion errors when attempting
+             ;; completion at point (bug#58148).  As Stefan suggested
+             ;; there: Silence messages [1], avoid compiler macros
+             ;; [2], and suppress all errors [3].
              (sexp
               (unwind-protect
-                  (let ((warning-minimum-log-level :emergency))
+                  (let ((inhibit-message t)                  ;[1]
+                        (macroexp-inhibit-compiler-macros t) ;[2]
+                        (warning-minimum-log-level :emergency))
                     (advice-add 'macroexpand-1 :around macroexpand-advice)
-                    (macroexpand-all sexp elisp--local-macroenv))
+                    (condition-case nil         ;[3]
+                        (macroexpand-all sexp elisp--local-macroenv)
+                      (t sexp)))
                 (advice-remove 'macroexpand-1 macroexpand-advice)))
              (vars (elisp--local-variables-1 nil sexp)))
         (delq nil
-- 
2.30.2

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Sat, 30 Sep 2023 09:56:09 -0400

> +                  (let ((inhibit-message t)     ;[1]
> +                        (warning-minimum-log-level :emergency))
>                      (advice-add 'macroexpand :around macroexpand-advice)
> -                    (macroexpand-all sexp))
> +                    (condition-case nil         ;[3]
> +                        (macroexpand-all sexp)
> +                      (t sexp)))

This `t` catches more than errors.  Better replace it with `error`.

> -                  (let ((warning-minimum-log-level :emergency))
> +                  (let ((inhibit-message t)                  ;[1]
> +                        (macroexp-inhibit-compiler-macros t) ;[2]
> +                        (warning-minimum-log-level :emergency))
>                      (advice-add 'macroexpand-1 :around macroexpand-advice)
> -                    (macroexpand-all sexp elisp--local-macroenv))
> +                    (condition-case nil         ;[3]
> +                        (macroexpand-all sexp elisp--local-macroenv)
> +                      (t sexp)))

What kind of errors are we expecting to catch with this
`condition-case`?  The pre-existing advice is supposed to catch macro
expansion errors, and the new let-binding is supposed to catch
compiler-macro errors, so it seems to me there aren't any *expected*
errors left.  If so, better remove this `condition-case` (or replace it
with `with-demoted-errors`) since all it has left to do is to hide any
real coding error that may come up and that we'd like to be told about.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: germanp82 <at> hotmail.com, 58396 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Sat, 30 Sep 2023 17:26:26 +0300

> Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org,
>  Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 30 Sep 2023 12:39:57 +0200
> From:  Jens Schmidt via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> >From cc663ccb14f3fae361733fe9742d7c7d07274d54 Mon Sep 17 00:00:00 2001
> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Date: Tue, 26 Sep 2023 22:26:15 +0200
> Subject: [PATCH] Silence macro expansion during completion-at-point
> 
> * lisp/progmodes/elisp-mode.el (elisp--local-variables): Silence
> messages.  Suppress all errors during macro expansion.  (Bug#58396)
> 
> Do not merge to master.
> ---
>  lisp/progmodes/elisp-mode.el | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
> index bd3916ce108..bc01058ff3c 100644
> --- a/lisp/progmodes/elisp-mode.el
> +++ b/lisp/progmodes/elisp-mode.el
> @@ -445,11 +445,19 @@ elisp--local-variables
>                                     (condition-case nil
>                                         (apply expander form args)
>                                       (error form))))
> +             ;; Avoid any macro expansion errors when attempting
> +             ;; completion at point (bug#58148).  As Stefan suggested
> +             ;; there: Silence messages [1] and suppress all errors
> +             ;; [3].  (Not avoiding compiler macros in the current
> +             ;; release branch, though.)

Most of this comment should be in the commit log message, I think, and
the [1] and [3] markers should be replaced with text telling what that
does.  Otherwise, the first patch is okay for the emacs-29 branch.

Regarding the second patch: if Stefan Monnier and Stefan Kangas are
okay with it, so am I.

Thanks.

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: German Pacenza <germanp82 <at> hotmail.com>, 58396 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
 58148 <at> debbugs.gnu.org
Subject: Re: bug#58148: 29.0.50; Wrong number of arguments in
 keymap-set--anon-cmacro
Date: Sat, 30 Sep 2023 20:44:55 +0200

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> +                  (let ((inhibit-message t)     ;[1]
>> +                        (warning-minimum-log-level :emergency))
>>                      (advice-add 'macroexpand :around macroexpand-advice)
>> -                    (macroexpand-all sexp))
>> +                    (condition-case nil         ;[3]
>> +                        (macroexpand-all sexp)
>> +                      (t sexp)))
>
> This `t` catches more than errors.  Better replace it with `error`.

Done plus Eli's comments from that other branch.

>> -                  (let ((warning-minimum-log-level :emergency))
>> +                  (let ((inhibit-message t)                  ;[1]
>> +                        (macroexp-inhibit-compiler-macros t) ;[2]
>> +                        (warning-minimum-log-level :emergency))
>>                      (advice-add 'macroexpand-1 :around macroexpand-advice)
>> -                    (macroexpand-all sexp elisp--local-macroenv))
>> +                    (condition-case nil         ;[3]
>> +                        (macroexpand-all sexp elisp--local-macroenv)
>> +                      (t sexp)))
>
> What kind of errors are we expecting to catch with this
> `condition-case`?  The pre-existing advice is supposed to catch macro
> expansion errors, and the new let-binding is supposed to catch
> compiler-macro errors, so it seems to me there aren't any *expected*
> errors left.  If so, better remove this `condition-case` (or replace it
> with `with-demoted-errors`) since all it has left to do is to hide any
> real coding error that may come up and that we'd like to be told about.

Done.

FWIW, bug#60081 can also be merged into this one.  (The other bugs that
Zehao mentions in her/his last post are either merged already or
typos/not related to this bug.)  Technically, I should be able to merge
that bug (after having been pointed to admin/notes/bugtracker), but is
it OK for me (as a "plain user") to do so?  Or should someone with more
authority do that?

Thanks.

[0001-29-Silence-macro-expansion-during-completion-at-point.patch (text/x-diff, inline)]

From f4184086081b9cf94e87848d33b527c35f78ffdf Mon Sep 17 00:00:00 2001
From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Date: Tue, 26 Sep 2023 22:26:15 +0200
Subject: [PATCH] Silence macro expansion during completion at point

To keep risk in the current release branch low, do not avoid compiler
macros as suggested by Stefan in the bug, but rather suppress all errors.

* lisp/progmodes/elisp-mode.el (elisp--local-variables): Silence
messages.  Suppress all errors during macro expansion.  (Bug#58148)

Do not merge to master.
---
 lisp/progmodes/elisp-mode.el | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index bd3916ce108..354d98c50dc 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -447,9 +447,14 @@ elisp--local-variables
                                      (error form))))
              (sexp
               (unwind-protect
-                  (let ((warning-minimum-log-level :emergency))
+                  ;; Silence any macro expansion errors when
+                  ;; attempting completion at point (bug#58148).
+                  (let ((inhibit-message t)
+                        (warning-minimum-log-level :emergency))
                     (advice-add 'macroexpand :around macroexpand-advice)
-                    (macroexpand-all sexp))
+                    (condition-case nil
+                        (macroexpand-all sexp)
+                      (error sexp)))
                 (advice-remove 'macroexpand macroexpand-advice)))
              (vars (elisp--local-variables-1 nil sexp)))
         (delq nil
-- 
2.30.2

[0001-30-Silence-macro-expansion-during-completion-at-point.patch (text/x-diff, inline)]

From cc954764667e23ecc19ae9cc3fb89956a32289ce Mon Sep 17 00:00:00 2001
From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Date: Fri, 29 Sep 2023 22:04:43 +0200
Subject: [PATCH] Silence macro expansion during completion at point

* lisp/emacs-lisp/macroexp.el (macroexp-inhibit-compiler-macros): Add
variable.
(macroexp--compiler-macro): Inspect that new variable and, if it is
non-nil, return the input form unchanged.
* lisp/progmodes/elisp-mode.el (elisp--local-variables): Silence
messages.  Avoid compiler macros.  (Bug#58148)
---
 lisp/emacs-lisp/macroexp.el  | 20 ++++++++++++++------
 lisp/progmodes/elisp-mode.el |  6 +++++-
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el
index 3ef924a5c73..6eb670d6dc1 100644
--- a/lisp/emacs-lisp/macroexp.el
+++ b/lisp/emacs-lisp/macroexp.el
@@ -105,13 +105,21 @@ macroexp--all-clauses
 	(macroexp--all-forms clause skip)
       clause)))
 
+(defvar macroexp-inhibit-compiler-macros nil
+  "Inhibit application of compiler macros if non-nil.")
+
 (defun macroexp--compiler-macro (handler form)
-  (condition-case-unless-debug err
-      (apply handler form (cdr form))
-    (error
-     (message "Warning: Optimization failure for %S: Handler: %S\n%S"
-              (car form) handler err)
-     form)))
+  "Apply compiler macro HANDLER to FORM and return the result.
+Unless `macroexp-inhibit-compiler-macros' is non-nil, in which
+case return FORM unchanged."
+  (if macroexp-inhibit-compiler-macros
+      form
+    (condition-case-unless-debug err
+        (apply handler form (cdr form))
+      (error
+       (message "Warning: Optimization failure for %S: Handler: %S\n%S"
+                (car form) handler err)
+       form))))
 
 (defun macroexp--funcall-if-compiled (_form)
   "Pseudo function used internally by macroexp to delay warnings.
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 664299df288..ff90a744ea3 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -460,7 +460,11 @@ elisp--local-variables
                    (message "Ignoring macroexpansion error: %S" err) form))))
              (sexp
               (unwind-protect
-                  (let ((warning-minimum-log-level :emergency))
+                  ;; Silence any macro expansion errors when
+                  ;; attempting completion at point (bug#58148).
+                  (let ((inhibit-message t)
+                        (macroexp-inhibit-compiler-macros t)
+                        (warning-minimum-log-level :emergency))
                     (advice-add 'macroexpand-1 :around macroexpand-advice)
                     (macroexpand-all sexp elisp--local-macroenv))
                 (advice-remove 'macroexpand-1 macroexpand-advice)))
-- 
2.30.2

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: germanp82 <at> hotmail.com, 58396 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca, 58148 <at> debbugs.gnu.org
Subject: Re: bug#58148: 29.0.50; Wrong number of arguments in
 keymap-set--anon-cmacro
Date: Sat, 30 Sep 2023 20:51:25 +0200

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

> Most of this comment should be in the commit log message, I think, and
> the [1] and [3] markers should be replaced with text telling what that
> does.  Otherwise, the first patch is okay for the emacs-29 branch.

Updated the patch accordingly and sent it on that other branch of this
thread, please review.  However, I removed the [1] and [3] markers
without replacement: I don't think that there is much need to separately
comment on a `condition-case' or a let-binding of `inhibit-message'.

> Regarding the second patch: if Stefan Monnier and Stefan Kangas are
> okay with it, so am I.

Does that mean that I should explicitly draw Stefan Kangas' attention to
this bug?  Or would he notice somehow otherwise?

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: germanp82 <at> hotmail.com, 58396 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca, 58148 <at> debbugs.gnu.org
Subject: Re: bug#58148: 29.0.50; Wrong number of arguments in
 keymap-set--anon-cmacro
Date: Sat, 30 Sep 2023 21:54:48 +0300

> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Cc: 58148 <at> debbugs.gnu.org,  germanp82 <at> hotmail.com,  58396 <at> debbugs.gnu.org,
>   larsi <at> gnus.org,  monnier <at> iro.umontreal.ca
> Date: Sat, 30 Sep 2023 20:51:25 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Most of this comment should be in the commit log message, I think, and
> > the [1] and [3] markers should be replaced with text telling what that
> > does.  Otherwise, the first patch is okay for the emacs-29 branch.
> 
> Updated the patch accordingly and sent it on that other branch of this
> thread, please review.

It's fine, thanks.

> > Regarding the second patch: if Stefan Monnier and Stefan Kangas are
> > okay with it, so am I.
> 
> Does that mean that I should explicitly draw Stefan Kangas' attention to
> this bug?  Or would he notice somehow otherwise?

Just wait for him to chime in, which will happen soon enough.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: germanp82 <at> hotmail.com, 58396 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Sat, 30 Sep 2023 15:03:44 -0700

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

> Regarding the second patch: if Stefan Monnier and Stefan Kangas are
> okay with it, so am I.

It looks fine to me.

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 58396 <at> debbugs.gnu.org
Subject: Re: bug#58396: 29.0.50; Optimization failure for add-to-list
Date: Tue, 03 Oct 2023 21:04:22 +0200

Gentle bump ...

Eli has OKed the (updated) patch for emacs-29, Eli and Stefan K have
OKed the (updated) patch for emacs-master, both updated patches and
their OK available on other branches of this bug.  So only your vote
seems to be missing here.

Could you please check?

Thanks.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 58148-done <at> debbugs.gnu.org, German Pacenza <germanp82 <at> hotmail.com>,
 60081-done <at> debbugs.gnu.org, 58396 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#58148: 29.0.50; Wrong number of arguments in
 keymap-set--anon-cmacro
Date: Thu, 05 Oct 2023 14:07:01 -0400

>> This `t` catches more than errors.  Better replace it with `error`.
> Done plus Eli's comments from that other branch.

Thanks, pushed to `emacs-29`.

> Done.

Thanks, pushed to `master`.

> FWIW, bug#60081 can also be merged into this one. (The other bugs that
> Zehao mentions in her/his last post are either merged already or
> typos/not related to this bug.)

Indeed, hereby closing it as well.

> Technically, I should be able to merge that bug (after having been
> pointed to admin/notes/bugtracker), but is it OK for me (as a "plain
> user") to do so?

Yes (it's easy to undo, in any case if it proves to be a mistake).


        Stefan

Previous Next

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