From: Spencer Baugh <sbaugh@janestreet.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros
Date: Fri, 15 Dec 2023 15:39:31 -0500 [thread overview]
Message-ID: <ier34w3kxoc.fsf@janestreet.com> (raw)
In-Reply-To: <83h6kjnrzg.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Dec 2023 22:14:11 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: larsi@gnus.org, 67837@debbugs.gnu.org, monnier@iro.umontreal.ca
>> Date: Fri, 15 Dec 2023 22:01:01 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>>
>> > This allows the keyboard macro is allowed to provide input even if
>> > inhibit-interaction=t.
>>
>> Please find a way of fixing the case of a keyboard macro that provides
>> input without adversely affecting the other cases where these
>> functions are called with inhibit-interaction=t.
>
> I'm actually tend to think that this proposal is fundamentally wrong,
> not just problematic implementation-wise. Providing input from a
> keyboard macro is still input, and inhibit-interaction=t means asking
> for input signals an error. So your suggestion subverts this feature,
> and therefore it is simply wrong to install something like that.
>
> IOW, signaling an error in these cases is exactly TRT, and we should
> not let keyboard macros circumvent this mechanism.
If that's the case, then could we add another variable which does behave
like I propose with these patches? That is, it allows input from
keyboard macros, but not from the user? That is personally what I want
in my packages, because it doesn't break users who use keyboard macros,
and it supports my use case of making read-char error in batch mode.
Or perhaps, another possible value of inhibit-interaction, which behaves
like that?
BTW, I'm curious to hear what Lars thinks, because I expect that
"keyboard macros should not work within inhibit-interaction=t" was not
at all part of the plan.
Although, I guess with my change, a keyboard macro which calls a
function which internally sets inhibit-interaction=t will effectively
ignore the inhibit-interaction setting. Which is definitely not
correct.
The correct behavior is a bit subtle; also important to consider are
kbd-macro-query and recursive-edit.
Here are some nesting situations, and what I suggest read-char should do
in each of them:
kmacro: get kmacro input
i-i=t: error
i-i=t, then kmacro: get kmacro input
kmacro, then i-i=t: error
i-i=t, kmacro, i-i=t: error
kmacro, i-i=t, kmacro: get inner kmacro input
kmacro, recursive-edit: get user input
i-i=t, recursive-edit: error
i-i=t, kmacro, recursive-edit: error
kmacro, i-i=t, recursive-edit: error
So basically, i-i=t means any request for user input should fail, which
my change achieves; but also, if i-i=t was bound *after* the kmacro,
then any request for kmacro input should also fail. Not sure how to
achieve that.
next prev parent reply other threads:[~2023-12-15 20:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 16:48 bug#67837: 29.1.90; inhibit-interaction breaks keyboard macros Spencer Baugh
2023-12-15 16:50 ` Spencer Baugh
2023-12-15 18:54 ` Eli Zaretskii
2023-12-15 19:48 ` Spencer Baugh
2023-12-15 20:01 ` Eli Zaretskii
2023-12-15 20:09 ` Spencer Baugh
2023-12-16 7:02 ` Eli Zaretskii
2023-12-16 13:22 ` sbaugh
2023-12-16 13:57 ` Eli Zaretskii
2023-12-15 20:14 ` Eli Zaretskii
2023-12-15 20:39 ` Spencer Baugh [this message]
2023-12-16 7:14 ` Eli Zaretskii
2023-12-16 15:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-16 16:08 ` Eli Zaretskii
2023-12-16 17:18 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-16 22:26 ` Spencer Baugh
2024-02-16 23:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 7:53 ` Eli Zaretskii
2024-02-17 14:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 14:35 ` Eli Zaretskii
2024-02-17 14:43 ` Eli Zaretskii
2024-02-17 15:15 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-17 16:07 ` Eli Zaretskii
2024-02-17 7:37 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ier34w3kxoc.fsf@janestreet.com \
--to=sbaugh@janestreet.com \
--cc=67837@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.