bug#32640: 26.1; Make `kill-process' a command

bug#32640: 26.1; Make `kill-process' a command

[Phil Sainty]

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

Not being able to use M-x kill-process (especially for killing

the current buffer's process) is something which has annoyed me
periodically.

[-- Attachment #2: kill-process-interactive.el --]
[-- Type: text/x-emacs-lisp, Size: 2304 bytes --]

;; Make `kill-process' a command.
;; (put 'kill-process 'interactive-form '(interactive))
(put 'kill-process 'interactive-form
     '(interactive (kill-process-read-arg)))

(defun kill-process-read-arg ()
  "Obtain arguments interactively for `kill-process'."
  ;; Currently supports only the PROCESS argument.
  ;; Must either return a list containing a process, or signal an error.
  ;; (Returning `nil' would mean the current buffer's process.)
  (unless (fboundp 'process-list)
    (error "Asynchronous subprocesses are not supported on this system"))
  ;; Local function to return cons of a complete-able name, and the
  ;; associated process object, for use with `completing-read'.
  (cl-flet ((procitem
             (p) (when (process-live-p p)
                   (let ((pid (process-id p))
                         (procname (process-name p))
                         (procbuf (process-buffer p)))
                     (and (eq (process-type p) 'real)
                          (cons (if procbuf
                                    (format "%s (%s) in buffer %s"
                                            procname pid
                                            (buffer-name procbuf))
                                  (format "%s (%s)" procname pid))
                                p))))))
    ;; Perform `completing-read' for a process.
    (let* ((currproc (get-buffer-process (current-buffer)))
           (proclist (or (process-list) (error "No processes found")))
           (collection (delq nil (mapcar #'procitem proclist)))
           (selection (completing-read
                       (if (and currproc (eq (process-type currproc) 'real))
                           (format "Kill process? (default %S (%s)): "
                                   currproc (process-id currproc))
                         "Kill process: ")
                       collection nil :require-match nil nil
                       (car (cl-find currproc collection :key #'cdr))))
           (process (and selection
                         (cdr (assoc selection collection)))))
      (unless process
        (error "No process selected"))
      ;; Return list of arguments for `kill-process'.
      (if (y-or-n-p (format "Kill %S? " process))
          (list process)
        (error "Process not killed")))))

bug#32640: 26.1; Make `kill-process' a command

[Phil Sainty]

(Apologies for the terseness of the previous message -- I managed
to send it accidentally when I'd barely started writing it.)

To repeat:

Not being able to use M-x kill-process (especially for killing
the current buffer's process) is something which has annoyed me
periodically.

`kill-process' is written in C, but it occurred to me to see
whether I could give it an interactive-form property, and was
pleased to find that it worked. What I've written seems to work
nicely -- a completing read over the `process-list' (filtered
by process-type `real'), and with the current buffer's process
provided by default.

I'm not proposing this (see attachment in previous message) as
a patch verbatim -- if this change was made, I would expect
`kill-process' to *directly* declare itself as interactive in
the C code -- but potentially `kill-process-read-arg' could be
used as I've written it (or similar) if that was agreeable?


-Phil

bug#32640: 26.1; Make `kill-process' a command

[Eli Zaretskii]

On September 5, 2018 12:32:53 PM GMT+03:00, Phil Sainty <psainty@orcon.net.nz> wrote:
> Not being able to use M-x kill-process (especially for killing
> 
> the current buffer's process) is something which has annoyed me
> periodically.

Is something wrong with signal-process?

bug#32640: 26.1; Make `kill-process' a command

[Phil Sainty]

On 05/09/18 22:23, Eli Zaretskii wrote:
> Is something wrong with signal-process?

I'd failed to notice that; but yes -- interactively, I don't think
that's as good as the changes I'm suggesting, as it doesn't provide
completion for either the process or the signal (not in 26.1, at any
rate), and it doesn't offer defaults for the argument values either.
As such, unless you know offhand the the correct process name or PID
to type at the prompt, it doesn't help very much?

Despite that command existing, I think it's still useful to make
`kill-process' interactive along the general lines of the code I
wrote; and it seems to me that `signal-process' could be likewise
improved to provide equivalent completion for the process, and to
add completion for the signals.

Presumably they could both use the same function for reading the
process interactively?


-Phil

bug#32640: 26.1; Make `kill-process' a command

[Michael Albinus]

Phil Sainty <psainty@orcon.net.nz> writes:

> Despite that command existing, I think it's still useful to make
> `kill-process' interactive along the general lines of the code I
> wrote; and it seems to me that `signal-process' could be likewise
> improved to provide equivalent completion for the process, and to
> add completion for the signals.

There's also `interrupt-process'. This has the additional feature to
send the SIGINT signal also to remote processes under Tramp control.

> -Phil

Best regards, Michael.

bug#32640: 26.1; Make `kill-process' a command

[Phil Sainty]

On 2018-09-06 01:37, Michael Albinus wrote:
> There's also `interrupt-process'. This has the additional feature to
> send the SIGINT signal also to remote processes under Tramp control.

Is `interrupt-process' unique in this regard, Michael?

Checking "(elisp)Signals to Processes" shows me all of:

      -- Function: interrupt-process &optional process current-group
      -- Function: kill-process &optional process current-group
      -- Function: quit-process &optional process current-group
      -- Function: stop-process &optional process current-group
      -- Function: continue-process &optional process current-group
      -- Command: signal-process process signal

I feel that `kill-process' is more of a special case than the others
(to my mind it's more likely for a user to want to kill an inferior
process than to want to send one of the other signals; but maybe
that's just me?).  So personally I'm not fussed about making all of
these things commands; but it seems that all of those functions could
share common code for obtaining interactive arguments, so presumably
if it was done for one then it would be very straightforward to
convert the others as well if that was seen as beneficial.


-Phil

bug#32640: 26.1; Make `kill-process' a command

[Michael Albinus]

Phil Sainty <psainty@orcon.net.nz> writes:

Hi Phil,

>> There's also `interrupt-process'. This has the additional feature to
>> send the SIGINT signal also to remote processes under Tramp control.
>
> Is `interrupt-process' unique in this regard, Michael?

Yes.

> -Phil

Best regards, Michael.

bug#32640: 26.1; Make `kill-process' a command

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> Checking "(elisp)Signals to Processes" shows me all of:
>
>      -- Function: interrupt-process &optional process current-group
>      -- Function: kill-process &optional process current-group
>      -- Function: quit-process &optional process current-group
>      -- Function: stop-process &optional process current-group
>      -- Function: continue-process &optional process current-group
>      -- Command: signal-process process signal
>
> I feel that `kill-process' is more of a special case than the others
> (to my mind it's more likely for a user to want to kill an inferior
> process than to want to send one of the other signals; but maybe
> that's just me?).  So personally I'm not fussed about making all of
> these things commands; but it seems that all of those functions could
> share common code for obtaining interactive arguments, so presumably
> if it was done for one then it would be very straightforward to
> convert the others as well if that was seen as beneficial.

I've added your process prompting function to Emacs 29 (with some
trivial changes).  I think it makes sense to make kill-process into a
command (because I think that's a command people want to have), so I've
now done that.  The other ones -- I don't think there's much demand for
having those as commands, but if we want to, it's now trivial to do.

But I think we should wait to do so to see if anybody requests that, so
I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no