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

[Michael Albinus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Hi Michael,

Hi Dmitry,

>>> 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'
>> Don't know. (shell-mode) is called in shell-command since bcad49851742
>> (1995-07-17). And it is called in tramp-handle-shell-command since
>> f5e29b9b70a5 (2011-09-04).
>> (comint-read-input-ring) is called in shell-mode since
>> (1993-10-22). There might be packages which trust on the
>> comint-input-ring existence for buffers in shell mode, even if such
>> buffers are created by shell-command..
>
> Yes, it would be an incompatibility - so we'll need to consider the
> migration path. See the attached patch - I suggest that any callers of
> 'shell-mode' that need the exact same input-ring setup also call
> shell-setup-input-ring (if it's fboundp - a version check).
>
> Or I suppose we could check the value of shell-setup-input-ring and
> skip history loading when it is empty. It's a more subtle
> incompatibility which might affect (or not) third-party code in
> similar ways.
>
> Either of the attached patches solves this part of the problem for me,
> please take your pick.

I'm really not convinced that we should change shell-mode in an
incompatible way for such a minor problem of (not) loading the remote
history file. shell-mode is one of the building blocks Emnacs consists of.

Instead we must give the user a config option to suppress this. I've
shown a possible way to do with my patch, but anything else, which keeps
compatibility of shell-mode, would do.

Eli?

Best regards, Michael.