Re: process-file instead of call-process in proced.el?

[Roland Winkler <winkler@gnu.org>]

On Sun, Mar 27 2022, Michael Albinus wrote:
> Michael Albinus <michael.albinus@gmx.de> writes:
>> I see. So if we don't want to emulate list-system-processes on a remote
>> host, we need another mean to determine, that a process is killed in a
>> sudo environment.
>
> I've prepared a first version of a patch (still missing documentation),
> see appended. The changes are:
>
> - `signal-process' is capable now to signal remote processes. This is
>   triggered when either the PROCESS object has the property `remote-pid'
>   (set by Tramp), or the PROCESS is just a number, and the additional
>   optional parameter REMOTE is a remote file name.
>
> - There is a new user option `proced-remote-directory', which defaults
>   to "/sudo::". When `proced-send-signal' or `proced-renice' are invoked
>   with a prefix arg ("C-u k" or "C-u r" in the *Proced* buffer), the
>   respective signal is sent with the credentials as identified by this
>   user option.

I have no meaningful scenario to test the code myself.  Just from
looking at the patch, I am wondering:

How is it supposed to work that one signals remote processes if
list-system-processes is not available on a remote host?  Say, how
should one find out the PIDs?  How does this integrate into proced that
is otherwise only running locally?

Maybe my ignorance stems from not having any usage scenarios in the
first place.