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

[Filipp Gunbin]

On 25/03/2022 15:12 +0300, Eli Zaretskii wrote:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Cc: Filipp Gunbin <fgunbin@fastmail.fm>,  winkler@gnu.org,  
>> emacs-devel@gnu.org
>> Date: Fri, 25 Mar 2022 12:46:06 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> The patch only changes call-process to process-file, to support file
>> >> handlers.  Setting "kill" into proced-signal-function is a user
>> >> customization.
>> >
>> > Sorry, from my POV fixing something means making it work as correctly
>> > as we can reasonably do.  If it didn't work correctly before, we
>> > should fix that as well, as part of any work on the relevant code.  I
>> > understand that, if the doing TRT is complicated, it could be left to
>> > a separate patch, but in this case it isn't complicated at all.
>> >
>> > So let's fix this part of proced to work on all supported platforms,
>> > okay?
>> 
>> I don't understand why an external "kill" process is applied. Couldn't
>> we simply call always `signal-process'? A comment in
>> `proced-send-signal' recommends this already.
>> 
>> Then we could give `signal-process' a handler, like `interrupt-process'
>> has already. (Well, we would need a mean to indicate, that a process-id
>> is meant for a remote host.)
>
> Yes, that'd be much better, IMO.

These are different things.  What Michael suggests would fix the case
for signal-process, which would be great.  But what I originally
suggested would fix the case for when proced-signal-function is
customized to something else, like "kill", for whatever reasons.  Then
it can be used like I described, running the command from "remote"
sudo/su buffer, whatever it be.

Filipp