[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue with remote async processes.
From: |
Michael Albinus |
Subject: |
Re: Issue with remote async processes. |
Date: |
Tue, 29 Mar 2022 19:45:02 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Ergus <spacibba@aol.com> writes:
> Hi:
Hi,
>>call-process is synchronous. Likely, you mean unification of
>>make-process and start{-file}-process? Technically, it would be possible
>>to obsolete start{-file}-process, make-process would be sufficient. But
>>there's ton of packages in the wild using that, so it might create more
>>trouble than it is worth for.
>>
> With the obsoletion policies in emacs you will have the function with
> the obsolete warning for the next 10 years probably... The packages that
> don't update during that time, probably may need to be removed too
> because that means they are abandoned.
10 years would be too long for me. No idea, whether I'll still use Emacs
then :-)
>>These days, writing new code, I would simply use make-process, that's it.
>>
> How do you use find-file-name-handler then? Just with :file-handler t?
Yes.
>>> The remote may unify process-file with call-process families
>>
>>Not so simple. There is a reason for call-process: a guarantee that it is
>>executed always locally, whatever default-directory.
>>
> Couldn't that be solved with the variable? I called it remote, but may
> call it `local` instead... so when local not-nil guarantees... But the
> idea is the same...
>
> You could even reuse the file-handler parameter for example??
We've discussed this decades ago, when process-file was invented. The
agreement was not to touch packages which use call-process for a reason,
even an additional customization of a variable would be too much. Here
we are ...
>>> That may reduce the 4 functions to a single one...
>>
>>I don't believe it will work. But perhaps we could at least bring the
>>arguments of the local process functions and the remote process
>>functions in line, at least for the stdout and stderr handling.
>>
> Please...
Hmm. Let's see. No promise!
>>It would be easy to add another property
>>remote-command which would keep a list of the program and its arguments.
>>
> Please... ;)
I've implemented this, pushed to master. The Tramp manual got a new
subsection:
--8<---------------cut here---------------start------------->8---
5.6.8 Process properties of asynchronous remote processes
---------------------------------------------------------
When available, TRAMP adds process properties to process objects of
asynchronous properties. However, it is not guaranteed that all these
properties are set.
• ‘remote-tty’
This is the name of the terminal a PROCESS uses on the remote
host, i.e., it reads and writes on.
• ‘remote-pid’
The process id of the command executed on the remote host. This
is used when sending signals remotely.
• ‘remote-command’
The remote command which has been invoked via ‘make-process’ or
‘start-file-process’, a list of strings (program and its
arguments). This does not show the additional shell sugar TRAMP
makes around the commands, in order to see this you must inspect
TRAMP *note traces: Traces and Profiles.
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
- Issue with remote async processes., Ergus, 2022/03/24
- Re: Issue with remote async processes., Michael Albinus, 2022/03/25
- Re: Issue with remote async processes., Ergus, 2022/03/26
- Re: Issue with remote async processes., Michael Albinus, 2022/03/27
- Re: Issue with remote async processes., Ergus, 2022/03/27
- Re: Issue with remote async processes., Michael Albinus, 2022/03/28
- Re: Issue with remote async processes., Ergus, 2022/03/28
- Re: Issue with remote async processes., Michael Albinus, 2022/03/29
- Re: Issue with remote async processes., Ergus, 2022/03/29
- Re: Issue with remote async processes.,
Michael Albinus <=