Hi Michael,

On 25/05/2024 13:49, Michael Albinus wrote:

>> 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.