bug#10107: 23.2; Add command gud-quit

bug#10107: 23.2; Add command gud-quit

[Krzysztof =17belechowski]

<menu-bar> <tools> <gdb> ls <RET> C-c q

C-c q is undefined.
Given input C-c q when no subprocess is being debugged, gud should quit.


In GNU Emacs 23.2.1 (i586-suse-linux-gnu, GTK+ Version 2.22.1)
 of 2011-02-22 on build27
Windowing system distributor `The X.Org Foundation', version 11.0.10903000
configured using `configure  '--with-pop' '--without-hesiod' '--with-kerberos' '--with-kerberos5' '--with-xim' '--enable-autodepend' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--with-x' '--with-sound' '--with-sync-input' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-rsvg' '--with-dbus' '--without-gpm' '--with-x-toolkit=gtk' '--x-includes=/usr/include' '--x-libraries=/usr/lib:/usr/share/X11' '--with-xft' '--with-libotf' '--with-m17n-flt' '--build=i586-suse-linux' 'build_alias=i586-suse-linux' 'CC=gcc-4.3' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE -std=gnu89 -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label -Wno-unprototyped-calls -fno-optimize-sibling-calls -DSYSTEM_PURESIZE_EXTRA=55000 	 -DSITELOAD_PURESIZE_EXTRA=10000 ' 'LDFLAGS=-Wl,-O2 -Wl,--hash-size=65521''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: pl_PL.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<f10> <menu-bar> <tools> <gdb> <help-echo> <backspace> 
<backspace> <backspace> <backspace> s <backspace> l 
s <return> C-x k <return> n o <return> C-c q M-x r 
e p o r t <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message idna sendmail regexp-opt ecomplete rfc822
mml easymenu mml-sec password-cache mm-decode mm-bodies mm-encode
mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev
nnheader gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit
mailheader canlock sha1 hex-util hashcash mail-utils emacsbug gdb-ui
byte-opt bytecomp byte-compile advice help-fns advice-preload bindat
json gud easy-mmode comint ring lpr disp-table tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote
make-network-process dbusbind system-font-setting font-render-setting
gtk x-toolkit x multi-tty emacs)

bug#10107: Acknowledgement (23.2; Add command gud-quit)

[Krzysztof Żelechowski]

You can type C-d C-x k to achieve this effect.

bug#10107: 23.2; Add command gud-quit

[Lars Ingebrigtsen]

giecrilj@stegny.2a.pl (Krzysztof =17belechowski) writes:

> <menu-bar> <tools> <gdb> ls <RET> C-c q
>
> C-c q is undefined.
> Given input C-c q when no subprocess is being debugged, gud should quit.

(I'm going through old bug reports that unfortunately got no response at
the time.)

I'm not sure I understand this bug report -- `C-c q' isn't a key binding
that any Emacs mode binds, so it's not surprising that it's not bound
here, either.

Did you mean some other key binding?

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

bug#10107: 23.2; Add command gud-quit

[Krzysztof Żelechowski]

Dnia środa, 2 czerwca 2021 09:35:26 CEST Lars Ingebrigtsen pisze:
> giecrilj@stegny.2a.pl (Krzysztof =17belechowski) writes:
> > <menu-bar> <tools> <gdb> ls <RET> C-c q
> > 
> > C-c q is undefined.
> > Given input C-c q when no subprocess is being debugged, gud should quit.
> 
> (I'm going through old bug reports that unfortunately got no response at
> the time.)
> 
> I'm not sure I understand this bug report -- `C-c q' isn't a key binding
> that any Emacs mode binds, so it's not surprising that it's not bound
> here, either.
> 
> Did you mean some other key binding?


This was meant as a feature request: add a command and bind it.

The idea behind this request was that there should be a command to kill the 
this buffer process.

HTH,
Chris

bug#10107: 23.2; Add command gud-quit

[Lars Ingebrigtsen]

Krzysztof Żelechowski <giecrilj@stegny.2a.pl> writes:

> The idea behind this request was that there should be a command to kill the 
> this buffer process.

`C-x k' kills any buffer -- isn't that as convenient as a new
hypothetical `C-c q' binding?  So I'm afraid I still don't understand
this request.

(The latter binding can't be added, though, since `C-c LETTER' is
reserved for users to bind.)

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

bug#10107: 23.2; Add command gud-quit

[Krzysztof Żelechowski]

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

Dnia niedziela, 6 czerwca 2021 11:16:44 CEST Lars Ingebrigtsen pisze:
> Krzysztof Żelechowski <giecrilj@stegny.2a.pl> writes:
> > The idea behind this request was that there should be a command to kill
> > the
> > this buffer process.
> 
> `C-x k' kills any buffer -- isn't that as convenient as a new
> hypothetical `C-c q' binding?  So I'm afraid I still don't understand
> this request.
> 
> (The latter binding can't be added, though, since `C-c LETTER' is
> reserved for users to bind.)


While the binding I chose might be inappropriate, the new command would kill the 
underlying process but leave the buffer for further examination.

Chris



[-- Attachment #2: Type: text/html, Size: 1893 bytes --]

bug#10107: 23.2; Add command gud-quit

[Lars Ingebrigtsen]

Krzysztof Żelechowski <giecrilj@stegny.2a.pl> writes:

> While the binding I chose might be inappropriate, the new command
> would kill the underlying process but leave the buffer for further
> examination.

Oh, I see -- you just want a command that kills the process in the
current buffer?

Sure, that's something that I think sounds generally useful (for
instance to kill an out-of-control process that's inserting something in
the buffer), and there doesn't seem to be such a command?

The `delete-process' function does this (with no parameters it'll kill
the process in the current buffer), so we could just slap an interactive
spec on it and make it a command.  (Assigning a keystroke to it might
perhaps be overkill.)

Anybody got any opinions here?

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

bug#10107: 23.2; Add command gud-quit

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 06 Jun 2021 14:50:23 +0200
> Cc: 10107@debbugs.gnu.org
> 
> Oh, I see -- you just want a command that kills the process in the
> current buffer?
> 
> Sure, that's something that I think sounds generally useful (for
> instance to kill an out-of-control process that's inserting something in
> the buffer), and there doesn't seem to be such a command?
> 
> The `delete-process' function does this (with no parameters it'll kill
> the process in the current buffer), so we could just slap an interactive
> spec on it and make it a command.  (Assigning a keystroke to it might
> perhaps be overkill.)

Why not invoke kill-process instead?

bug#10107: 23.2; Add command gud-quit

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why not invoke kill-process instead?

delete-process is more general (works on all process-like things) and
therefore seems more useful as a user-level command.

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

bug#10107: 23.2; Add command gud-quit

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: giecrilj@stegny.2a.pl,  10107@debbugs.gnu.org
> Date: Sun, 06 Jun 2021 15:05:01 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why not invoke kill-process instead?
> 
> delete-process is more general (works on all process-like things) and
> therefore seems more useful as a user-level command.

But the OP wanted to kill only real subprocesses, no?

bug#10107: 23.2; Add command gud-quit

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> delete-process is more general (works on all process-like things) and
>> therefore seems more useful as a user-level command.
>
> But the OP wanted to kill only real subprocesses, no?

The OP only wanted a command for gud buffers, but I think that if we
want to have a command here, we should make it generally useful.  And
I don't see any downsides to using delete-process instead of
kill-process here, but perhaps I'm overlooking something?

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

bug#10107: 23.2; Add command gud-quit

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: giecrilj@stegny.2a.pl,  10107@debbugs.gnu.org
> Date: Tue, 08 Jun 2021 11:36:42 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> delete-process is more general (works on all process-like things) and
> >> therefore seems more useful as a user-level command.
> >
> > But the OP wanted to kill only real subprocesses, no?
> 
> The OP only wanted a command for gud buffers, but I think that if we
> want to have a command here, we should make it generally useful.  And
> I don't see any downsides to using delete-process instead of
> kill-process here, but perhaps I'm overlooking something?

If we want a general-purpose command to kill a subprocess, we already
have Proced.  Do we really need yet another way?

I thought the issue was with killing a runaway process in GUD, which
is a specialized situation which I can sympathize (having myself been
in that situation once or twice...)

bug#10107: 23.2; Add command gud-quit

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If we want a general-purpose command to kill a subprocess, we already
> have Proced.  Do we really need yet another way?

`M-x list-processes' is perhaps more relevant -- proced seems to just
list all processes on the system?

> I thought the issue was with killing a runaway process in GUD, which
> is a specialized situation which I can sympathize (having myself been
> in that situation once or twice...)

`delete-process' will delete any runaway process (in the current buffer)
-- I've had the same experience in other buffers.

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

bug#10107: 23.2; Add command gud-quit

[Krzysztof Żelechowski]

Dnia niedziela, 6 czerwca 2021 14:50:23 CEST Lars Ingebrigtsen pisze:
> Krzysztof Żelechowski <giecrilj@stegny.2a.pl> writes:
> > While the binding I chose might be inappropriate, the new command
> > would kill the underlying process but leave the buffer for further
> > examination.
> 
> Oh, I see -- you just want a command that kills the process in the
> current buffer?
> 
> Sure, that's something that I think sounds generally useful (for
> instance to kill an out-of-control process that's inserting something in
> the buffer), and there doesn't seem to be such a command?
> 
> The `delete-process' function does this (with no parameters it'll kill
> the process in the current buffer), so we could just slap an interactive
> spec on it and make it a command.  (Assigning a keystroke to it might
> perhaps be overkill.)

Imagine yourself as an operator at the Knight Capital Group.  You can see 
ongoing damage but you still want to preserve the log.  What would you rather  
use, a keyboard accelerator or a long command?

Chris

bug#10107: 23.2; Add command gud-quit

[Eli Zaretskii]

> From: Krzysztof Żelechowski <giecrilj@stegny.2a.pl>
> Date: Sun, 06 Jun 2021 15:04:27 +0200
> Cc: 10107@debbugs.gnu.org
> 
> > (Assigning a keystroke to it might perhaps be overkill.)
> 
> Imagine yourself as an operator at the Knight Capital Group.  You can see 
> ongoing damage but you still want to preserve the log.  What would you rather  
> use, a keyboard accelerator or a long command?

Any user can always bind this command to any key they want.  Lars was
talking about having a binding _by_default_.

bug#10107: 23.2; Add command gud-quit

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, I see -- you just want a command that kills the process in the
> current buffer?
>
> Sure, that's something that I think sounds generally useful (for
> instance to kill an out-of-control process that's inserting something in
> the buffer), and there doesn't seem to be such a command?

I've now made `delete-process' into a command in Emacs 29.

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