[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue with remote async processes.

From: Ergus
Subject: Re: Issue with remote async processes.
Date: Tue, 29 Mar 2022 13:46:38 +0200


I wonder about this because I find myself modifiying packages constantly
to use them with tramp.

On Tue, Mar 29, 2022 at 10:55:38AM +0200, Michael Albinus wrote:
Ergus <> writes:


So far I have complains with the emacs process API, there are many
function sometimes redundant and with confusing similar names, some of
them are only available for one specific case (like process-lines*,
which is available as a wrapper of call-process but not for the
process-file case considering if there is a find-file-name-handler)...

It is just history ...

But from the practical point of view it is very confusing to keep this
interface just because of this...

I would actually expect a simpler function interface with two extra
parameters (remote async).

The async may unify make-process and call-process families

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.

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?

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

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.


An extra comment:

(process-command process) always returns `/bin/sh -i` when the process
was executed remotely. I understand the reasons, but I am not sure if
this is intended... I mean, I am interested in the real executed command
when it failed for example. (either the complete one or the one passed
to start-file-process)

Is there a way to retrieve the full command like when the process
executed locally??

Not yet (you must look into the Tramp traces). Maybe you write a
wishlist bug report? Tramp adds already the remote-pid and remote-tty
properties to process objects. It would be easy to add another property
remote-command which would keep a list of the program and its arguments.

Please... ;)

Again, thanks in advance, Ergus

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]