* bug#47991: 28.0.50; inconsistency between async-shell-command and shell-command
@ 2021-04-24 10:38 Zhiwei Chen
2021-04-24 10:57 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Zhiwei Chen @ 2021-04-24 10:38 UTC (permalink / raw)
To: 47991
shell-command pops a buffer in fundamental-mode while
async-shell-command is in shell-mode.
AFAIK, async-shell-command is implemented via shell-command with an
additional '&' sign if it doesn't end with it.
To reproduce:
emacs -Q
M-x shell-command SPC ls RET
M-x async-shell-command SPC ls RET
--
Zhiwei Chen
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47991: 28.0.50; inconsistency between async-shell-command and shell-command
2021-04-24 10:38 bug#47991: 28.0.50; inconsistency between async-shell-command and shell-command Zhiwei Chen
@ 2021-04-24 10:57 ` Eli Zaretskii
2021-04-25 16:38 ` Zhiwei Chen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2021-04-24 10:57 UTC (permalink / raw)
To: Zhiwei Chen; +Cc: 47991
> From: Zhiwei Chen <condy0919@gmail.com>
> Date: Sat, 24 Apr 2021 18:38:12 +0800
>
>
> shell-command pops a buffer in fundamental-mode while
> async-shell-command is in shell-mode.
That's a feature.
Why do you want the buffer in shell-mode when the command is run
synchronously?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47991: 28.0.50; inconsistency between async-shell-command and shell-command
2021-04-24 10:57 ` Eli Zaretskii
@ 2021-04-25 16:38 ` Zhiwei Chen
2021-04-25 16:50 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Zhiwei Chen @ 2021-04-25 16:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 47991
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Zhiwei Chen <condy0919@gmail.com>
>> Date: Sat, 24 Apr 2021 18:38:12 +0800
>>
>>
>> shell-command pops a buffer in fundamental-mode while
>> async-shell-command is in shell-mode.
>
> That's a feature.
>
> Why do you want the buffer in shell-mode when the command is run
> synchronously?
The original intention is to make `async-shell-command` and
`shell-command` default to `evil-normal-state' by adding a hook in which
checks if `this-command' is `shell-command' or `async-shell-command'.
As a result, I found that they behave differently. It looks too odd that
`async-shell-command' is implemented in `shell-command' but it has a
different semantic.
Since the buffer is in `fundamental-mode', there is no way to access
`shell-mode-map' where user maybe define their own bindings.
I'm curious about the reason why it's a feature. Why the synchronous
`shell-command' should be in `fundamental-mode' while the async doesn't.
--
Zhiwei Chen
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47991: 28.0.50; inconsistency between async-shell-command and shell-command
2021-04-25 16:38 ` Zhiwei Chen
@ 2021-04-25 16:50 ` Eli Zaretskii
2021-04-26 4:41 ` Richard Stallman
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2021-04-25 16:50 UTC (permalink / raw)
To: Zhiwei Chen, Richard Stallman; +Cc: 47991
> From: Zhiwei Chen <condy0919@gmail.com>
> Cc: 47991@debbugs.gnu.org
> Date: Mon, 26 Apr 2021 00:38:10 +0800
>
> I'm curious about the reason why it's a feature. Why the synchronous
> `shell-command' should be in `fundamental-mode' while the async doesn't.
I don't know, it's been that way since 1995. Maybe Richard remembers.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47991: 28.0.50; inconsistency between async-shell-command and shell-command
2021-04-25 16:50 ` Eli Zaretskii
@ 2021-04-26 4:41 ` Richard Stallman
2021-05-02 9:11 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2021-04-26 4:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: condy0919, 47991
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > I'm curious about the reason why it's a feature. Why the synchronous
> > `shell-command' should be in `fundamental-mode' while the async doesn't.
> I don't know, it's been that way since 1995. Maybe Richard remembers.
This decision seems correct to me.
The code of Shell mode is mainly meant for (1) handling the output as
it arrives asynchronously and (2) editing shell input.
In M-!, there is no need for either of those things.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#47991: 28.0.50; inconsistency between async-shell-command and shell-command
2021-04-26 4:41 ` Richard Stallman
@ 2021-05-02 9:11 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-02 9:11 UTC (permalink / raw)
To: Richard Stallman; +Cc: condy0919, 47991
Richard Stallman <rms@gnu.org> writes:
> The code of Shell mode is mainly meant for (1) handling the output as
> it arrives asynchronously and (2) editing shell input.
>
> In M-!, there is no need for either of those things.
So it doesn't sound like we want to change this, and I'm closing this
bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-05-02 9:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-04-24 10:38 bug#47991: 28.0.50; inconsistency between async-shell-command and shell-command Zhiwei Chen
2021-04-24 10:57 ` Eli Zaretskii
2021-04-25 16:38 ` Zhiwei Chen
2021-04-25 16:50 ` Eli Zaretskii
2021-04-26 4:41 ` Richard Stallman
2021-05-02 9:11 ` 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).