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

From: Dmitry Gutov <[email-masked]>
Date: Wed, 29 May 2024 14:55:43 +0300

Hi Michael,

On 29/05/2024 10:41, Michael Albinus wrote:

>>> I've puzzled the appended patch together. It does the following:
>>> - Obey 'tramp-histfile-override' also for direct async processes.
>>
>> Thank you.
> 
> So that's consensus.

Yes, of course.

>>> - Use 'tramp-histfile-override' in 'shell-mode', whether the remote
>>>     history file shall be read. A value of t suppresses this.
>>> - Support connection-local setting of 'tramp-histfile-override' in
>>>     'shell'. Use something like
>>> --8<---------------cut here---------------start------------->8---
>>>     (connection-local-set-profile-variables
>>>      'remote-tramp-histfile-override '((tramp-histfile-override . nil)))
>>>     (connection-local-set-profiles
>>>      '(:application tramp :machine "remotehost")
>>>      'remote-tramp-histfile-override)
>>> --8<---------------cut here---------------end--------------->8---
>>> - Support connection-local setting of 'tramp-histfile-override' in
>>>     'shell-command'. In order to distinguish this from the setting for
>>>     'shell', another :application is used ('shell-command' instead of
>>>     'tramp'). Use something like
>>> --8<---------------cut here---------------start------------->8---
>>>     (connection-local-set-profile-variables
>>>      'another-tramp-histfile-override '((tramp-histfile-override . t)))
>>>     (connection-local-set-profiles
>>>      '(:application shell-command :machine "remotehost")
>>>      'another-tramp-histfile-override)
>>> --8<---------------cut here---------------end--------------->8---
>>> It is recommended to set 'tramp-histfile-override' to t for
>>> asynchronous processes. Comments?
>>
>> It seems like more work, and more code, to get to the same
>> result.
> 
> For whom? The changes in Emacs are small.

Bigger than in my patches anyway. And the user's customization is an 
extra piece that people fill have to figure out as well.

> A user doesn't need connection-local variables. Only in case, she wants
> different settings for different applications, like shell and
> shell-command. Otherwise, a global setting of tramp-histfile-override
> would be sufficient.

I think the original report and our consensus that the behavior is wrong 
more or less concludes that shell and shell-command should behave 
differently in this regard (by default). Does it not?

>> Also, it would not get the OOtB improvement for the "not M-x
>> shell" case - IIUC the user would have to create a new profile to
>> enact the distinction. That's a relatively complex thing to do.
> 
> No. Only if *different* values for *different* applications are
> needed. And the other places in Emacs, which use shell-mode, wouldn't
> profit (yet) from connection-local variables, but they would profit from
> tramp-histfile-override setting in general. This is an improvement to
> the status quo.

It's indeed an improvement, but it applied to my patches as well, except 
they don't require an additional customization for this to happen.

>> So... it's not up to me, and the problem doesn't touch me too deeply,
>> but I think my solution for the second part is preferable.
> 
> You mean shell-no-start-prog.diff? That hard-codes a different behavior
> in shell-mode, and I'm not so familiar with shell-mode and comint that I
> can exclude collateral damages.

Right. The potential for collateral seems very low to me, and there is a 
migration path for such callers anyway. But let's see what others think.