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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 31 May 2024 08:53:32 +0300

> Date: Fri, 31 May 2024 03:24:49 +0300
> Cc: Eli Zaretskii <[email-masked]>, [email-masked]
> From: Dmitry Gutov <[email-masked]>
> 
> >> Thank you. I haven't tested this personally either, but it seems like
> >> this is the behavior we will want by default.
> >>
> >> So the proposed solution should include it, I think.
> > In order to not misunderstand: you agree the solution based on
> > tramp-histfile-override now, don't you?
> 
> Just to be frank: I don't like the approach, but I do think it's better 
> than the status quo. In that sense, I agree with it, if none other is 
> accepted.
> 
> But, well, in the meantime I came up with a couple of new solutions:
> 
> 1) [first patch] We can add a new major mode, for 'M-&' to use instead 
> of the full-blown 'shell-mode' - it could be very simple: just apply 
> font-lock keywords and maybe set list-buffers-directory.

I think I'm okay with this.  (It needs to be prominently documented,
of course.)  But we need a documented way for people to get previous
behavior if they want that.  How would that work?

> Problems? I suppose someone might be using shell-mode-hook to do 
> something in the async-shell-command output buffer, and it won't fire 
> anymore. Seemingly very minor concern.

Can't we run shell-mode-hook inside this new mode's mode hook?  Then
this problem goes away.

> 2) [second patch] async-shell-command could set shell--start-prog (it's 
> permanent-local) to `none', and then shell-mode will check for that 
> value, and if set to this value, skip the input ring setup.
> 
> Downsides? Pretty ad-hoc approach. And any external code looking up this 
> (private) variable could be surprised by the new value.

Yes, which is why I like this one less.

Thanks.