Re: Issue with remote async processes.

[Ergus]

Hi:

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 <spacibba@aol.com> writes:
>
> Hi,
>
> > 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.
Please...

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