GNU bug report logs -
#79663
31.0.50; emacs-lisp-macroexpand
Previous Next
To reply to this bug, email your comments to 79663 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 14:47:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Helmut Eller <eller.helmut <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 20 Oct 2025 14:47:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
What would you think about changing emacs-lisp-macroexpand so that the
expansion is displayed in a separate buffer?
Like with this patch:
[0001-Some-changes-to-emacs-lisp-macroexpand.patch (text/x-diff, inline)]
From edd8bd259f934552ea89b71da8c38332e7439a56 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut <at> gmail.com>
Date: Mon, 20 Oct 2025 16:30:34 +0200
Subject: [PATCH] Some changes to emacs-lisp-macroexpand
Display the expanded form in a separate buffer.
Add a emacs-lisp-macroexpand-all command.
Create key bindings at C-c C-m and C-c C-M-m.
* lisp/progmodes/elisp-mode.el (emacs-lisp--macroexpand): Factored
out from emacs-lisp-macroexpand.
(emacs-lisp-macroexpand): Use it
(emcas-lisp-macroexpand-all): New command.
(emacs-lisp-mode-map): Bind them.
(emacs-lisp--pp): New helper.
---
lisp/progmodes/elisp-mode.el | 40 ++++++++++++++++++++++--------------
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index af7c8b96555..a140ebc8c1a 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -56,7 +56,9 @@ emacs-lisp-mode-map
"C-c C-e" #'elisp-eval-region-or-buffer
"C-c C-f" #'elisp-byte-compile-file
"C-c C-b" #'elisp-byte-compile-buffer
- "C-M-q" #'indent-pp-sexp)
+ "C-M-q" #'indent-pp-sexp
+ "C-c C-m" #'emacs-lisp-macroexpand
+ "C-c C-M-m" #'emacs-lisp-macroexpand-all)
(easy-menu-define emacs-lisp-mode-menu emacs-lisp-mode-map
"Menu for Emacs Lisp mode."
@@ -240,20 +242,28 @@ emacs-lisp-native-compile-and-load
(when-let* ((byte-file (emacs-lisp-native-compile)))
(load (file-name-sans-extension byte-file))))
-(defun emacs-lisp-macroexpand ()
- "Macroexpand the form after point.
-Comments in the form will be lost."
- (interactive)
- (let* ((start (point))
- (exp (read (current-buffer)))
- ;; Compute it before, since it may signal errors.
- (new (macroexpand-1 exp)))
- (if (equal exp new)
- (message "Not a macro call, nothing to expand")
- (delete-region start (point))
- (pp new (current-buffer))
- (if (bolp) (delete-char -1))
- (indent-region start (point)))))
+(defun emacs-lisp--pp (form)
+ (with-output-to-temp-buffer "*Pp Output*"
+ (pp form)
+ (with-current-buffer standard-output
+ (emacs-lisp-mode))))
+
+(defun emacs-lisp--macroexpand (form expand)
+ (let ((expansion (funcall expand form)))
+ (cond ((eq expansion form)
+ (message "Nothing to expand"))
+ (t
+ (emacs-lisp--pp expansion)))))
+
+(defun emacs-lisp-macroexpand (form)
+ "Macroexpand the sexp at point and display it in a buffer."
+ (interactive (list (sexp-at-point)))
+ (emacs-lisp--macroexpand form #'macroexpand-1))
+
+(defun emacs-lisp-macroexpand-all (form)
+ "Fully macroexpand the sexp at point and display it in a buffer."
+ (interactive (list (sexp-at-point)))
+ (emacs-lisp--macroexpand form #'macroexpand-all))
(defun elisp-mode-syntax-propertize (start end)
(goto-char start)
--
2.47.3
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 15:08:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 79663 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Mon, 20 Oct 2025 16:45:09 +0200
>
> What would you think about changing emacs-lisp-macroexpand so that the
> expansion is displayed in a separate buffer?
This can only be an opt-in behavior, since the command is very old.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 15:37:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 79663 <at> debbugs.gnu.org (full text, mbox):
On Mon, Oct 20 2025, Eli Zaretskii wrote:
1>> From: Helmut Eller <eller.helmut <at> gmail.com>
>> Date: Mon, 20 Oct 2025 16:45:09 +0200
>>
>> What would you think about changing emacs-lisp-macroexpand so that the
>> expansion is displayed in a separate buffer?
>
> This can only be an opt-in behavior, since the command is very old.
I could call the new version differently, like elisp-macroexpand,
and keep the old version around. Would that work?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 16:00:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 79663 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 79663 <at> debbugs.gnu.org
> Date: Mon, 20 Oct 2025 17:35:46 +0200
>
> On Mon, Oct 20 2025, Eli Zaretskii wrote:
>
> 1>> From: Helmut Eller <eller.helmut <at> gmail.com>
> >> Date: Mon, 20 Oct 2025 16:45:09 +0200
> >>
> >> What would you think about changing emacs-lisp-macroexpand so that the
> >> expansion is displayed in a separate buffer?
> >
> > This can only be an opt-in behavior, since the command is very old.
>
> I could call the new version differently, like elisp-macroexpand,
> and keep the old version around. Would that work?
Yes, that'd be fine. (Of course, the final changeset should include a
NEWS entry and perhaps also an update for the manual(s).)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 16:53:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 79663 <at> debbugs.gnu.org (full text, mbox):
>> What would you think about changing emacs-lisp-macroexpand so that the
>> expansion is displayed in a separate buffer?
>
> This can only be an opt-in behavior, since the command is very old.
Like 'C-x C-e' prints in the echo area, and 'C-u C-x C-e' inserts
in the current buffer, 'emacs-lisp-macroexpand' could use the prefix arg
as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 17:16:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79663 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Helmut Eller <eller.helmut <at> gmail.com>, Stefan Monnier
> <monnier <at> iro.umontreal.ca>, 79663 <at> debbugs.gnu.org
> Date: Mon, 20 Oct 2025 19:46:23 +0300
>
> >> What would you think about changing emacs-lisp-macroexpand so that the
> >> expansion is displayed in a separate buffer?
> >
> > This can only be an opt-in behavior, since the command is very old.
>
> Like 'C-x C-e' prints in the echo area, and 'C-u C-x C-e' inserts
> in the current buffer, 'emacs-lisp-macroexpand' could use the prefix arg
> as well.
Yes, that's also possible. Or we could have a new command, say,
emacs-lisp-macroexpand-other-window.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 18:22:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79663 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon 20 Oct 2025 at 05:35pm +02, Helmut Eller wrote:
> On Mon, Oct 20 2025, Eli Zaretskii wrote:
>
> 1>> From: Helmut Eller <eller.helmut <at> gmail.com>
>>> Date: Mon, 20 Oct 2025 16:45:09 +0200
>>>
>>> What would you think about changing emacs-lisp-macroexpand so that the
>>> expansion is displayed in a separate buffer?
>>
>> This can only be an opt-in behavior, since the command is very old.
>
> I could call the new version differently, like elisp-macroexpand,
> and keep the old version around. Would that work?
A few comments from me:
- Please give it a more meaningful name instead of just exploiting
"elisp" vs "emacs-lisp", which have the same semantic content.
I would like to suggest 'emacs-lisp-macroexpand-other-window'.
- How about using a prefix argument for the difference between
emacs-lisp-macroexpand and emacs-lisp-macroexpand-all, instead of a
whole separate binding?
- We've talked before about sorting out the copyright assignment so that
we can have macrostep.el in Emacs core.
That doesn't need to block adding your new command, but let's think
about the choice of key binding for your new command with the possible
future addition of macrostep.el in mind.
macrostep-expand is the main entry point for that library. Can we
think of key bindings for macrostep-expand, emacs-lisp-macroexpand and
emacs-lisp-macroexpand-all that make sense a mnemonic trio, that's
easy to memorise? Next to your two new bindings we can have a comment
recording our idea for a complementary binding for macrostep-expand.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 19:16:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 79663 <at> debbugs.gnu.org (full text, mbox):
On Mon, Oct 20 2025, Sean Whitton wrote:
>> I could call the new version differently, like elisp-macroexpand,
>> and keep the old version around. Would that work?
>
> A few comments from me:
>
> - Please give it a more meaningful name instead of just exploiting
> "elisp" vs "emacs-lisp", which have the same semantic content.
> I would like to suggest 'emacs-lisp-macroexpand-other-window'.
Or emacs-lisp-pp-macroexpand.
> - How about using a prefix argument for the difference between
> emacs-lisp-macroexpand and emacs-lisp-macroexpand-all, instead of a
> whole separate binding?
Tradionally there are macroexpand-1, macroexpand, and macroexpand-all.
In my .emacs, the prefix argument selects macroexpand, because that is
the least interesting.
There is also the issue with pp-macroexpand-last-sexp, which does the
same as my emacs-lisp-macroexpand, expect that it uses the expression
before point. Mabye the prefix argument should be used for that.
> - We've talked before about sorting out the copyright assignment so that
> we can have macrostep.el in Emacs core.
>
> That doesn't need to block adding your new command, but let's think
> about the choice of key binding for your new command with the possible
> future addition of macrostep.el in mind.
>
> macrostep-expand is the main entry point for that library. Can we
> think of key bindings for macrostep-expand, emacs-lisp-macroexpand and
> emacs-lisp-macroexpand-all that make sense a mnemonic trio, that's
> easy to memorise? Next to your two new bindings we can have a comment
> recording our idea for a complementary binding for macrostep-expand.
I'm in no hurry. I had these commands in my .emacs for many years.
They can stay there for a few more.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Mon, 20 Oct 2025 20:02:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 79663 <at> debbugs.gnu.org (full text, mbox):
I've never used any of those things (I typically call `macroexpand` by
hand in a IELM thingy instead), so I'm wondering what it is we
should be aiming for.
I guess the kind of interface I can imagine is:
- A single command.
- Maybe C-u or a config var controls whether to do it "inplace" or in
a temp buffer.
- Like `macrostep-mode`, immediately after the call use a transient
minor mode which lets you do things like "expand more/less" and maybe
jump between the "inplace" and "in a temp buffer", ...
And hopefully that should let us mark `pp-macroexpand-last-sexp` and
`emacs-lisp-macroexpand` as obsolete.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Thu, 23 Oct 2025 16:25:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 79663 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Oct 20 2025, Eli Zaretskii wrote:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: Helmut Eller <eller.helmut <at> gmail.com>, Stefan Monnier
>> <monnier <at> iro.umontreal.ca>, 79663 <at> debbugs.gnu.org
>> Date: Mon, 20 Oct 2025 19:46:23 +0300
>>
>> >> What would you think about changing emacs-lisp-macroexpand so that the
>> >> expansion is displayed in a separate buffer?
>> >
>> > This can only be an opt-in behavior, since the command is very old.
>>
>> Like 'C-x C-e' prints in the echo area, and 'C-u C-x C-e' inserts
>> in the current buffer, 'emacs-lisp-macroexpand' could use the prefix arg
>> as well.
>
> Yes, that's also possible. Or we could have a new command, say,
> emacs-lisp-macroexpand-other-window.
Depending on the prefix arg, this updated patch does the following:
- default (prefix-arg = 1): display the expansion in a separate buffer
- prefix-arg > 1: same as default, but with macroexpand-all
- prefix-arg = -1: replaces the current sexp, similar to the old command
- prefix-arg < -1: like -1, but with macroexpand-all
The prefix-arg = 0 is not used. I suppose it could be used for
macro-step mode. pp-macroexpand-last-sexp would remain a separate
command.
WDYT?
[0001-Some-changes-to-emacs-lisp-macroexpand.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Thu, 23 Oct 2025 16:58:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 79663 <at> debbugs.gnu.org (full text, mbox):
Hi Helmut.
> Depending on the prefix arg, this updated patch does the following:
>
> - default (prefix-arg = 1): display the expansion in a separate buffer
> - prefix-arg > 1: same as default, but with macroexpand-all
> - prefix-arg = -1: replaces the current sexp, similar to the old command
> - prefix-arg < -1: like -1, but with macroexpand-all
We generally try to shy away from such complex prefix arrangements.
So maybe in keeping with that tradition we could instead do:
- Prefix arg chooses "inplace-vs-inwindow".
- Use `macroexpand-1` at first.
- Immediate repetition switches to `macroexpand-all`.
WDYT?
> + (interactive (list (prefix-numeric-value current-prefix-arg)
> + (sexp-at-point)
> + (bounds-of-thing-at-point 'sexp)))
I'd compute the form from the bounds (in the body of the function
rather than in the interactive spec) rather than calling thingatpt twice.
> + (cond ((= arg 1)
> + (emacs-lisp--macroexpand form #'macroexpand-1 nil))
> + ((> arg 1)
> + (emacs-lisp--macroexpand form #'macroexpand-all nil))
> + ((= arg -1)
> + (emacs-lisp--macroexpand form #'macroexpand-1 bounds))
> + ((< arg -1)
> + (emacs-lisp--macroexpand form #'macroexpand-all bounds))
> + (t
> + (error "Invalid prefix-arg: %S" arg))))
And I'd move this into the `interactive` form.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Fri, 24 Oct 2025 06:32:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 79663 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: Juri Linkov <juri <at> linkov.net>, monnier <at> iro.umontreal.ca,
> 79663 <at> debbugs.gnu.org
> Date: Thu, 23 Oct 2025 18:24:25 +0200
>
> On Mon, Oct 20 2025, Eli Zaretskii wrote:
>
> >> From: Juri Linkov <juri <at> linkov.net>
> >> Cc: Helmut Eller <eller.helmut <at> gmail.com>, Stefan Monnier
> >> <monnier <at> iro.umontreal.ca>, 79663 <at> debbugs.gnu.org
> >> Date: Mon, 20 Oct 2025 19:46:23 +0300
> >>
> >> >> What would you think about changing emacs-lisp-macroexpand so that the
> >> >> expansion is displayed in a separate buffer?
> >> >
> >> > This can only be an opt-in behavior, since the command is very old.
> >>
> >> Like 'C-x C-e' prints in the echo area, and 'C-u C-x C-e' inserts
> >> in the current buffer, 'emacs-lisp-macroexpand' could use the prefix arg
> >> as well.
> >
> > Yes, that's also possible. Or we could have a new command, say,
> > emacs-lisp-macroexpand-other-window.
>
> Depending on the prefix arg, this updated patch does the following:
>
> - default (prefix-arg = 1): display the expansion in a separate buffer
>
> - prefix-arg > 1: same as default, but with macroexpand-all
>
> - prefix-arg = -1: replaces the current sexp, similar to the old command
>
> - prefix-arg < -1: like -1, but with macroexpand-all
>
> The prefix-arg = 0 is not used. I suppose it could be used for
> macro-step mode. pp-macroexpand-last-sexp would remain a separate
> command.
>
> WDYT?
This again changes the default behavior of an existing command, by
showing the expansion in another window, doesn't it? Or did I miss
something? I thought we agreed to make this an opt-in behavior?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Fri, 24 Oct 2025 07:45:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 79663 <at> debbugs.gnu.org (full text, mbox):
On Fri, Oct 24 2025, Eli Zaretskii wrote:
>> Depending on the prefix arg, this updated patch does the following:
>>
>> - default (prefix-arg = 1): display the expansion in a separate buffer
>>
>> - prefix-arg > 1: same as default, but with macroexpand-all
>>
>> - prefix-arg = -1: replaces the current sexp, similar to the old command
>>
>> - prefix-arg < -1: like -1, but with macroexpand-all
>>
>> The prefix-arg = 0 is not used. I suppose it could be used for
>> macro-step mode. pp-macroexpand-last-sexp would remain a separate
>> command.
>>
>> WDYT?
>
> This again changes the default behavior of an existing command, by
> showing the expansion in another window, doesn't it? Or did I miss
> something? I thought we agreed to make this an opt-in behavior?
Ok. I give up. You can close this bug.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Fri, 24 Oct 2025 10:36:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 79663 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: juri <at> linkov.net, monnier <at> iro.umontreal.ca, 79663 <at> debbugs.gnu.org
> Date: Fri, 24 Oct 2025 09:44:30 +0200
>
> On Fri, Oct 24 2025, Eli Zaretskii wrote:
>
> >> Depending on the prefix arg, this updated patch does the following:
> >>
> >> - default (prefix-arg = 1): display the expansion in a separate buffer
> >>
> >> - prefix-arg > 1: same as default, but with macroexpand-all
> >>
> >> - prefix-arg = -1: replaces the current sexp, similar to the old command
> >>
> >> - prefix-arg < -1: like -1, but with macroexpand-all
> >>
> >> The prefix-arg = 0 is not used. I suppose it could be used for
> >> macro-step mode. pp-macroexpand-last-sexp would remain a separate
> >> command.
> >>
> >> WDYT?
> >
> > This again changes the default behavior of an existing command, by
> > showing the expansion in another window, doesn't it? Or did I miss
> > something? I thought we agreed to make this an opt-in behavior?
>
> Ok. I give up. You can close this bug.
Why give up and close? It should be very easy to change the code so
that the function displays as before by default, while prefix argument
would then trigger the new behavior that you wanted to have. What am
I missing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Fri, 24 Oct 2025 16:10:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 79663 <at> debbugs.gnu.org (full text, mbox):
On Fri, Oct 24 2025, Eli Zaretskii wrote:
>> From: Helmut Eller <eller.helmut <at> gmail.com>
>> Cc: juri <at> linkov.net, monnier <at> iro.umontreal.ca, 79663 <at> debbugs.gnu.org
>> Date: Fri, 24 Oct 2025 09:44:30 +0200
>>
>> On Fri, Oct 24 2025, Eli Zaretskii wrote:
>>
>> >> Depending on the prefix arg, this updated patch does the following:
>> >>
>> >> - default (prefix-arg = 1): display the expansion in a separate buffer
>> >>
>> >> - prefix-arg > 1: same as default, but with macroexpand-all
>> >>
>> >> - prefix-arg = -1: replaces the current sexp, similar to the old command
>> >>
>> >> - prefix-arg < -1: like -1, but with macroexpand-all
>> >>
>> >> The prefix-arg = 0 is not used. I suppose it could be used for
>> >> macro-step mode. pp-macroexpand-last-sexp would remain a separate
>> >> command.
>> >>
>> >> WDYT?
>> >
>> > This again changes the default behavior of an existing command, by
>> > showing the expansion in another window, doesn't it? Or did I miss
>> > something? I thought we agreed to make this an opt-in behavior?
>>
>> Ok. I give up. You can close this bug.
>
> Why give up and close? It should be very easy to change the code so
> that the function displays as before by default, while prefix argument
> would then trigger the new behavior that you wanted to have. What am
> I missing?
I don't need the in-place behavior; keeping it makes this more complex
than I like. Maybe somebody can turn this into something coherent,
simple and useful. I can't.
Helmut
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Sat, 25 Oct 2025 06:36:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 79663 <at> debbugs.gnu.org (full text, mbox):
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: juri <at> linkov.net, monnier <at> iro.umontreal.ca, 79663 <at> debbugs.gnu.org
> Date: Fri, 24 Oct 2025 18:09:37 +0200
>
> On Fri, Oct 24 2025, Eli Zaretskii wrote:
>
> >> From: Helmut Eller <eller.helmut <at> gmail.com>
> >> Cc: juri <at> linkov.net, monnier <at> iro.umontreal.ca, 79663 <at> debbugs.gnu.org
> >> Date: Fri, 24 Oct 2025 09:44:30 +0200
> >>
> >> On Fri, Oct 24 2025, Eli Zaretskii wrote:
> >>
> >> >> Depending on the prefix arg, this updated patch does the following:
> >> >>
> >> >> - default (prefix-arg = 1): display the expansion in a separate buffer
> >> >>
> >> >> - prefix-arg > 1: same as default, but with macroexpand-all
> >> >>
> >> >> - prefix-arg = -1: replaces the current sexp, similar to the old command
> >> >>
> >> >> - prefix-arg < -1: like -1, but with macroexpand-all
> >> >>
> >> >> The prefix-arg = 0 is not used. I suppose it could be used for
> >> >> macro-step mode. pp-macroexpand-last-sexp would remain a separate
> >> >> command.
> >> >>
> >> >> WDYT?
> >> >
> >> > This again changes the default behavior of an existing command, by
> >> > showing the expansion in another window, doesn't it? Or did I miss
> >> > something? I thought we agreed to make this an opt-in behavior?
> >>
> >> Ok. I give up. You can close this bug.
> >
> > Why give up and close? It should be very easy to change the code so
> > that the function displays as before by default, while prefix argument
> > would then trigger the new behavior that you wanted to have. What am
> > I missing?
>
> I don't need the in-place behavior; keeping it makes this more complex
> than I like.
Then how about introducing a user option that will make the behavior
you want the default? That should be easy enough and not complicated.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79663; Package
emacs.
(Thu, 06 Nov 2025 13:23:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 79663 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon 20 Oct 2025 at 04:00pm -04, Stefan Monnier wrote:
> I've never used any of those things (I typically call `macroexpand` by
> hand in a IELM thingy instead), so I'm wondering what it is we
> should be aiming for.
>
> I guess the kind of interface I can imagine is:
>
> - A single command.
> - Maybe C-u or a config var controls whether to do it "inplace" or in
> a temp buffer.
> - Like `macrostep-mode`, immediately after the call use a transient
> minor mode which lets you do things like "expand more/less" and maybe
> jump between the "inplace" and "in a temp buffer", ...
>
> And hopefully that should let us mark `pp-macroexpand-last-sexp` and
> `emacs-lisp-macroexpand` as obsolete.
Very nice. I like this design.
Using C-u for in-place vs other-window makes sense to me.
And if it's expandable then we might not need the three variants,
macroexpand, macroexpand-1, and macroexpand-all, at all.
--
Sean Whitton
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.