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 04:59:43 +0300

Hi Michael,

On 26/05/2024 17:18, Michael Albinus wrote:

>>> So it seems to me that fixing shell-mode would be good for the default
>>> behavior, and then one could use tramp-histfile-override to add extra
>>> performance on top.
>>
>> I'll see whether I could make it more fine-grained, for example by
>> distinguishing the shell and shell-command cases.
> 
> I've puzzled the appended patch together. It does the following:
> 
> - Obey 'tramp-histfile-override' also for direct async processes.

Thank you.

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

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.

Maybe Eli will want to make that choice now.

Thanks,
Dmitry