GNU bug report logs -
#71049
async-shell-command ends with "Process *Async Shell Command* finished" when remote "direct-async-process"
Previous Next
Reported by: Dmitry Gutov <dmitry <at> gutov.dev>
Date: Sun, 19 May 2024 00:20:02 UTC
Severity: normal
Done: Dmitry Gutov <dmitry <at> gutov.dev>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 1 year and 81 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.