* bug#29334: 25.3; compiled commands don't respect special interactive expressions
@ 2017-11-17 6:17 Allen Li
2017-11-17 14:55 ` Drew Adams
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Allen Li @ 2017-11-17 6:17 UTC (permalink / raw)
To: 29334
Repro:
1. emacs -Q
2. Mark some text in the buffer
3. M-x append-to-buffer RET *scratch* RET
4. C-x ESC ESC
Expected last command:
(append-to-buffer "*scratch*" (region-beginning) (region-end))
Actual last command:
(append-to-buffer "*scratch*" 1 145)
If you then go and re-evaluate append-to-buffer (thus loading the
source version instead of the compiled version, you get
(append-to-buffer "*scratch*" (region-beginning) (region-end))
Thus, it looks like the compiled command doesn't handle special
interactive forms correctly.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2017-11-17 6:17 bug#29334: 25.3; compiled commands don't respect special interactive expressions Allen Li
@ 2017-11-17 14:55 ` Drew Adams
2018-01-04 5:25 ` Stefan Monnier
2017-11-21 19:45 ` Glenn Morris
2022-02-10 7:56 ` Lars Ingebrigtsen
2 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2017-11-17 14:55 UTC (permalink / raw)
To: Allen Li, 29334
> 1. emacs -Q
> 2. Mark some text in the buffer
> 3. M-x append-to-buffer RET *scratch* RET
> 4. C-x ESC ESC
>
> Expected last command:
>
> (append-to-buffer "*scratch*" (region-beginning) (region-end))
>
> Actual last command:
>
> (append-to-buffer "*scratch*" 1 145)
>
> If you then go and re-evaluate append-to-buffer (thus loading the
> source version instead of the compiled version, you get
>
> (append-to-buffer "*scratch*" (region-beginning) (region-end))
>
> Thus, it looks like the compiled command doesn't handle special
> interactive forms correctly.
Yes, thank you! This is something that has bugged me
for a while. This change is actually a regression (or
else on purpose?), introduced in Emacs 24. In all
Emacs releases prior to 24 it works as a user expects.
Dunno whether this bug report might be a duplicate. It
seems unlikely that no one (including me) has reported
this before. It reduces the utility of `C-x ESC ESC'
considerably.
An inexperienced user will likely give up altogether
trying to use such a command with `C-x ESC ESC', if
not give up on `C-x ESC ESC' entirely, through not
fully understanding. And an experienced user has
the annoyance of having to edit the hard-coded values
to get the behavior expected.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2017-11-17 6:17 bug#29334: 25.3; compiled commands don't respect special interactive expressions Allen Li
2017-11-17 14:55 ` Drew Adams
@ 2017-11-21 19:45 ` Glenn Morris
2017-11-24 3:11 ` Noam Postavsky
2022-02-10 7:56 ` Lars Ingebrigtsen
2 siblings, 1 reply; 10+ messages in thread
From: Glenn Morris @ 2017-11-21 19:45 UTC (permalink / raw)
To: Allen Li; +Cc: 29334
Allen Li wrote:
> 1. emacs -Q
> 2. Mark some text in the buffer
> 3. M-x append-to-buffer RET *scratch* RET
> 4. C-x ESC ESC
>
> Expected last command:
>
> (append-to-buffer "*scratch*" (region-beginning) (region-end))
>
> Actual last command:
>
> (append-to-buffer "*scratch*" 1 145)
Bisected to a46481370, our old friend "Use lexical-binding".
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2017-11-21 19:45 ` Glenn Morris
@ 2017-11-24 3:11 ` Noam Postavsky
2017-11-24 7:58 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2017-11-24 3:11 UTC (permalink / raw)
To: Glenn Morris; +Cc: 29334, Allen Li
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
tags 29334 + patch
quit
Glenn Morris <rgm@gnu.org> writes:
> Bisected to a46481370, our old friend "Use lexical-binding".
How about this:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 2783 bytes --]
From a8b43e98c592c84957ea304a0dc2d6423af9c5c5 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Thu, 23 Nov 2017 21:57:09 -0500
Subject: [PATCH] Fix command repetition with lexical-binding (Bug#29334)
`call-interactively' relies on analyzing the source of `interactive'
forms in order to preserve arguments like (region-end) in the command
history, rather than just storing the resulting position. However,
the byte-compiler does not preserve the source of the interactive form
when lexical-binding is in effect, because `call-interactively' would
evaluate the form with dynamic binding in that case.
To fix this, change `call-interactively' so that it checks compiled
functions for lexical-binding as well. Then the byte-compiler can
preserve the source of interactive forms regardless of the value of
lexical-binding.
* src/callint.c (Fcall_interactively): Functions compiled with
lexical-binding have their arglist encoded as an integer, use this to
choose the right kind of binding for compiled functions too.
* lisp/emacs-lisp/bytecomp.el (byte-compile-lambda): Preserve the
uncompiled form of the interactive form when lexical-binding is
enabled too.
---
lisp/emacs-lisp/bytecomp.el | 6 +-----
src/callint.c | 4 +++-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 590db570c5..e16405f09b 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -2823,11 +2823,7 @@ byte-compile-lambda
(while (consp (cdr form))
(setq form (cdr form)))
(setq form (car form)))
- (if (and (eq (car-safe form) 'list)
- ;; The spec is evalled in callint.c in dynamic-scoping
- ;; mode, so just leaving the form unchanged would mean
- ;; it won't be eval'd in the right mode.
- (not lexical-binding))
+ (if (eq (car-safe form) 'list)
nil
(setq int `(interactive ,newform)))))
((cdr int)
diff --git a/src/callint.c b/src/callint.c
index 5d88082e38..48ea9ba7a3 100644
--- a/src/callint.c
+++ b/src/callint.c
@@ -356,7 +356,9 @@ DEFUN ("call-interactively", Fcall_interactively, Scall_interactively, 1, 3, 0,
/* Compute the arg values using the user's expression. */
specs = Feval (specs,
CONSP (funval) && EQ (Qclosure, XCAR (funval))
- ? CAR_SAFE (XCDR (funval)) : Qnil);
+ ? CAR_SAFE (XCDR (funval))
+ : COMPILEDP (funval) && INTEGERP (AREF (funval, COMPILED_ARGLIST))
+ ? Qt : Qnil);
if (events != num_input_events || !NILP (record_flag))
{
/* We should record this command on the command history. */
--
2.11.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2017-11-24 3:11 ` Noam Postavsky
@ 2017-11-24 7:58 ` Eli Zaretskii
2017-11-24 12:17 ` Noam Postavsky
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2017-11-24 7:58 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 29334, vianchielfaura
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 23 Nov 2017 22:11:23 -0500
> Cc: 29334@debbugs.gnu.org, Allen Li <vianchielfaura@gmail.com>
>
> > Bisected to a46481370, our old friend "Use lexical-binding".
>
> How about this:
>
> >From a8b43e98c592c84957ea304a0dc2d6423af9c5c5 Mon Sep 17 00:00:00 2001
> From: Noam Postavsky <npostavs@gmail.com>
> Date: Thu, 23 Nov 2017 21:57:09 -0500
> Subject: [PATCH] Fix command repetition with lexical-binding (Bug#29334)
>
> `call-interactively' relies on analyzing the source of `interactive'
> forms in order to preserve arguments like (region-end) in the command
> history, rather than just storing the resulting position. However,
> the byte-compiler does not preserve the source of the interactive form
> when lexical-binding is in effect, because `call-interactively' would
> evaluate the form with dynamic binding in that case.
>
> To fix this, change `call-interactively' so that it checks compiled
> functions for lexical-binding as well. Then the byte-compiler can
> preserve the source of interactive forms regardless of the value of
> lexical-binding.
Thanks. If no objections are voiced to this approach, please push it
to the master branch. I think this is too radical for the release
branch.
P.S. Should this change be reflected in the ELisp manual somehow?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2017-11-24 7:58 ` Eli Zaretskii
@ 2017-11-24 12:17 ` Noam Postavsky
2018-01-04 2:56 ` Noam Postavsky
0 siblings, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2017-11-24 12:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 29334, vianchielfaura
Eli Zaretskii <eliz@gnu.org> writes:
>> To fix this, change `call-interactively' so that it checks compiled
>> functions for lexical-binding as well. Then the byte-compiler can
>> preserve the source of interactive forms regardless of the value of
>> lexical-binding.
>
> Thanks. If no objections are voiced to this approach, please push it
> to the master branch. I think this is too radical for the release
> branch.
Hah, okay, but that was the conservative approach! The radical one
would be resolving this FIXME:
static void
fix_command (Lisp_Object input, Lisp_Object values)
{
/* FIXME: Instead of this ugly hack, we should provide a way for an
interactive spec to return an expression/function that will re-build the
args without user intervention. */
> P.S. Should this change be reflected in the ELisp manual somehow?
I don't see where.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2017-11-24 12:17 ` Noam Postavsky
@ 2018-01-04 2:56 ` Noam Postavsky
2018-01-07 2:55 ` Noam Postavsky
0 siblings, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2018-01-04 2:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 29334, vianchielfaura
tags 29334 fixed
close 29334 27.1
quit
Noam Postavsky <npostavs@users.sourceforge.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> To fix this, change `call-interactively' so that it checks compiled
>>> functions for lexical-binding as well. Then the byte-compiler can
>>> preserve the source of interactive forms regardless of the value of
>>> lexical-binding.
>>
>> Thanks. If no objections are voiced to this approach, please push it
>> to the master branch. I think this is too radical for the release
>> branch.
Pushed to master.
[1: ce48658191]: 2018-01-03 20:51:28 -0500
Fix command repetition with lexical-binding (Bug#29334)
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce48658191befb7734a7af484e368af5ed8b9447
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2017-11-17 14:55 ` Drew Adams
@ 2018-01-04 5:25 ` Stefan Monnier
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2018-01-04 5:25 UTC (permalink / raw)
To: Drew Adams; +Cc: 29334, Allen Li
> Yes, thank you! This is something that has bugged me
> for a while. This change is actually a regression (or
> else on purpose?), introduced in Emacs 24.
Indeed. As for the question in parenthesis, yes I consciously decided
to break this "ugly hack" back then, wondering how much time it would
take for people to notice it (and hoping I'd find the time/motivation
to "do it right" in the mean time).
> Hah, okay, but that was the conservative approach! The radical one
> would be resolving this FIXME:
>
> static void
> fix_command (Lisp_Object input, Lisp_Object values)
> {
> /* FIXME: Instead of this ugly hack, we should provide a way for an
> interactive spec to return an expression/function that will re-build the
> args without user intervention. */
E.g. we could allow the interactive spec to return either a list of
argument *values*, or a list of argument *expressions* (and we could
distinguish the two by having the second be a vector instead of a list,
for example).
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2018-01-04 2:56 ` Noam Postavsky
@ 2018-01-07 2:55 ` Noam Postavsky
0 siblings, 0 replies; 10+ messages in thread
From: Noam Postavsky @ 2018-01-07 2:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 29334, vianchielfaura
notfixed 29334 27.1
reopen 29334
tag 29334 - fixed patch
quit
Noam Postavsky <npostavs@users.sourceforge.net> writes:
> Pushed to master.
>
> [1: ce48658191]: 2018-01-03 20:51:28 -0500
> Fix command repetition with lexical-binding (Bug#29334)
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce48658191befb7734a7af484e368af5ed8b9447
Turns out this doesn't actually work, so I've reverted it.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29988#11
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29334: 25.3; compiled commands don't respect special interactive expressions
2017-11-17 6:17 bug#29334: 25.3; compiled commands don't respect special interactive expressions Allen Li
2017-11-17 14:55 ` Drew Adams
2017-11-21 19:45 ` Glenn Morris
@ 2022-02-10 7:56 ` Lars Ingebrigtsen
2 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-10 7:56 UTC (permalink / raw)
To: Allen Li; +Cc: 29334
Allen Li <vianchielfaura@gmail.com> writes:
> 1. emacs -Q
> 2. Mark some text in the buffer
> 3. M-x append-to-buffer RET *scratch* RET
> 4. C-x ESC ESC
>
> Expected last command:
>
> (append-to-buffer "*scratch*" (region-beginning) (region-end))
>
> Actual last command:
>
> (append-to-buffer "*scratch*" 1 145)
This bug is still present in Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-02-10 7:56 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-17 6:17 bug#29334: 25.3; compiled commands don't respect special interactive expressions Allen Li
2017-11-17 14:55 ` Drew Adams
2018-01-04 5:25 ` Stefan Monnier
2017-11-21 19:45 ` Glenn Morris
2017-11-24 3:11 ` Noam Postavsky
2017-11-24 7:58 ` Eli Zaretskii
2017-11-24 12:17 ` Noam Postavsky
2018-01-04 2:56 ` Noam Postavsky
2018-01-07 2:55 ` Noam Postavsky
2022-02-10 7:56 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).