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

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71049 <at> debbugs.gnu.org
Subject: bug#71049: async-shell-command ends with "Process *Async Shell Command* finished" when remote "direct-async-process"
Date: Sat, 25 May 2024 17:51:22 +0200

Dmitry Gutov <dmitry <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.