Subject: bug#71049: async-shell-command ends with "Process *Async Shell Command* finished" when remote "direct-async-process"

From: Eli Zaretskii <[email-masked]>
Date: Wed, 29 May 2024 21:11:10 +0300

> Date: Wed, 29 May 2024 20:26:26 +0300
> Cc: [email-masked], [email-masked]
> From: Dmitry Gutov <[email-masked]>
> 
> On 29/05/2024 15:46, Eli Zaretskii wrote:
> >> Seems so. The patches (two alternatives) are attached to
> >> https://debbugs.gnu.org/71049#53.
> > Thanks.  I don't understand what they do in the context of this
> > discussion, probably because I don't know enough about shell-mode and
> > comint.  Could you explain the intent, please?
> 
> Okay, to summarize the previous messages:
> 
> async-shell-command calls shell-mode, which loads the history file by 
> calling comint-read-input-ring.
> 
> shell-setup-input-ring.diff extracts the comint input ring setup to a 
> separate function. That function is then only called by 'shell', but not 
> by 'shell-mode' itself anymore, or any of its descendants. Any callers 
> or descendants of it that actually need this setup (I'm not aware of 
> any, but they might exist) will need to adapt by adding this call.
> 
> shell-no-start-prog.diff does not move the logic, but predicates its 
> execution on the value of the variable shell--start-prog being non-nil. 
> In-tree it's only set by 'shell', so the result is the same. The "how to 
> adapt" recipe would be setting shell--start-prog to non-nil (in callers).

Thanks.  I think I'd prefer the changes in this respect to affect only
remote commands.  Since reading the local history file is almost
instantaneous, risking to break some use case we don't think about
sounds unjustified.  Let's fix the problem where it exists without too
many waves.