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

[Dmitry Gutov]

On 25/05/2024 20:00, Michael Albinus wrote:

> I'll have another idea.
>
> shell-mode checks already, whether the histfile is equal
> null-device. That works for the local case only.
>
> However, in Tramp there is tramp-histfile-override. It let's you decide
> whether you want to use the remote histfile, or use a histfile given by
> a file name, or don't use a histfile.
>
> This works for normal sync and async processes, but not for direct async
> processes (IIRC). Let's see whether I could extend this mechanism, and
> provide shell-mode proper information.

Obeying tramp-histfile-override sounds like it will be an improvement, 
thank you.

> If a user sets tramp-histfile-override to t or "/dev/null", shell-mode
> should not read the remote histfile. Users are already conditioned to
> set this user option :-)

But when used it would still regress on bug#36742, right? I'm not 100% 
sure what most of the users want in this area, but it appears as if at 
least one wanted to have access to command history.

And unlike when using async-shell-command, users of 'M-x shell' probably 
can afford to wait a little longer for the history to load (in all 
likelihood the new buffer will live longer, over multiple user inputs).

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.