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

[Dmitry Gutov]

On 24/05/2024 21:55, Eli Zaretskii wrote:
> > From: Michael Albinus <michael.albinus@gmx.de>
> > Cc: dmitry@gutov.dev,  71049@debbugs.gnu.org
> > Date: Fri, 24 May 2024 18:39:21 +0200
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > Can you explain the effect of that option on the scenarios that
> > > started this bug report?  I don't think I have a clear understanding
> > > of that.
> >
> > We're speaking about shell-mode. Let's try the command
> > [...]
> > 6 roundtrips to insert the remote history file into a buffer which we
> > don't need. Just for a single asynchronous "ls" command.
> >
> > With the new user option, this could be avoided by a user setting.
>
> Thanks.  But that's not what I thought I was asking about, see below.
>
> However, as long as we are talking about reading the history file: why
> does async-shell-command need the history file?  (I understand why
> shell-mode does, but async-shell-command is not shell-mode.)

The answer is that async-shell-command uses shell-mode as the major mode 
for the output buffer. For syntax highlighting, I guess.

You make a good point that the shell history for such buffers would 
usually make no sense - even if the running process takes user input 
(usually not, but sometimes it might) - its input history would be 
different from the shell.

So maybe we could just move the last form in shell-mode (which 
initializes comint-input-ring) to 'shell'

> > > Why is the process being called by such bogus names anyway?
> >
> > I don't understand. Which bogus names?
>
> I thought this was about the original complaints, whtch started this
> bug report, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71049#5.
> The fact that the history file was being read sounded as a side issue,
> at least at first.  So my question was about these messages:
>
>    Process *Async Shell Command* finished
>    -l: finished.
>
> I thought the option you suggest is intended to make these "process
> names" be more reasonable.  I guess I am confused, and the discussion
> moved to the "side issue" of preventing the unnecessary reading of the
> history file?

These are two separate (but correlated) issues in one bug report.