unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#10107: 23.2; Add command gud-quit
@ 2011-11-22 12:20 Krzysztof =17belechowski
       [not found] ` <handler.10107.B.132196456729471.ack@debbugs.gnu.org>
  2021-06-02  7:35 ` bug#10107: 23.2; Add command gud-quit Lars Ingebrigtsen
  0 siblings, 2 replies; 15+ messages in thread
From: Krzysztof =17belechowski @ 2011-11-22 12:20 UTC (permalink / raw)
  To: 10107

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: Acknowledgement (23.2; Add command gud-quit)
       [not found] ` <handler.10107.B.132196456729471.ack@debbugs.gnu.org>
@ 2011-11-24  7:14   ` Krzysztof Żelechowski
  0 siblings, 0 replies; 15+ messages in thread
From: Krzysztof Żelechowski @ 2011-11-24  7:14 UTC (permalink / raw)
  To: 10107

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2011-11-22 12:20 bug#10107: 23.2; Add command gud-quit Krzysztof =17belechowski
       [not found] ` <handler.10107.B.132196456729471.ack@debbugs.gnu.org>
@ 2021-06-02  7:35 ` Lars Ingebrigtsen
  2021-06-03 16:54   ` Krzysztof Żelechowski
  1 sibling, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-02  7:35 UTC (permalink / raw)
  To: Krzysztof =17belechowski; +Cc: 10107

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-02  7:35 ` bug#10107: 23.2; Add command gud-quit Lars Ingebrigtsen
@ 2021-06-03 16:54   ` Krzysztof Żelechowski
  2021-06-06  9:16     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 15+ messages in thread
From: Krzysztof Żelechowski @ 2021-06-03 16:54 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 10107

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







^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-03 16:54   ` Krzysztof Żelechowski
@ 2021-06-06  9:16     ` Lars Ingebrigtsen
  2021-06-06 11:58       ` Krzysztof Żelechowski
  0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-06  9:16 UTC (permalink / raw)
  To: Krzysztof Żelechowski; +Cc: 10107

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-06  9:16     ` Lars Ingebrigtsen
@ 2021-06-06 11:58       ` Krzysztof Żelechowski
  2021-06-06 12:50         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 15+ messages in thread
From: Krzysztof Żelechowski @ 2021-06-06 11:58 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 10107

[-- 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 --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-06 11:58       ` Krzysztof Żelechowski
@ 2021-06-06 12:50         ` Lars Ingebrigtsen
  2021-06-06 12:59           ` Eli Zaretskii
  2021-06-06 13:04           ` Krzysztof Żelechowski
  0 siblings, 2 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-06 12:50 UTC (permalink / raw)
  To: Krzysztof Żelechowski; +Cc: 10107

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-06 12:50         ` Lars Ingebrigtsen
@ 2021-06-06 12:59           ` Eli Zaretskii
  2021-06-06 13:05             ` Lars Ingebrigtsen
  2021-06-06 13:04           ` Krzysztof Żelechowski
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2021-06-06 12:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 10107, giecrilj

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-06 12:50         ` Lars Ingebrigtsen
  2021-06-06 12:59           ` Eli Zaretskii
@ 2021-06-06 13:04           ` Krzysztof Żelechowski
  2021-06-06 13:12             ` Eli Zaretskii
  1 sibling, 1 reply; 15+ messages in thread
From: Krzysztof Żelechowski @ 2021-06-06 13:04 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 10107

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









^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-06 12:59           ` Eli Zaretskii
@ 2021-06-06 13:05             ` Lars Ingebrigtsen
  2021-06-06 13:10               ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-06 13:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 10107, giecrilj

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-06 13:05             ` Lars Ingebrigtsen
@ 2021-06-06 13:10               ` Eli Zaretskii
  2021-06-08  9:36                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2021-06-06 13:10 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 10107, giecrilj

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-06 13:04           ` Krzysztof Żelechowski
@ 2021-06-06 13:12             ` Eli Zaretskii
  0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2021-06-06 13:12 UTC (permalink / raw)
  To: Krzysztof Żelechowski; +Cc: 10107, larsi

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-06 13:10               ` Eli Zaretskii
@ 2021-06-08  9:36                 ` Lars Ingebrigtsen
  2021-06-08 11:34                   ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-08  9:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 10107, giecrilj

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-08  9:36                 ` Lars Ingebrigtsen
@ 2021-06-08 11:34                   ` Eli Zaretskii
  2021-06-08 11:41                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2021-06-08 11:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 10107, giecrilj

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#10107: 23.2; Add command gud-quit
  2021-06-08 11:34                   ` Eli Zaretskii
@ 2021-06-08 11:41                     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-08 11:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 10107, giecrilj

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-06-08 11:41 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-22 12:20 bug#10107: 23.2; Add command gud-quit Krzysztof =17belechowski
     [not found] ` <handler.10107.B.132196456729471.ack@debbugs.gnu.org>
2011-11-24  7:14   ` bug#10107: Acknowledgement (23.2; Add command gud-quit) Krzysztof Żelechowski
2021-06-02  7:35 ` bug#10107: 23.2; Add command gud-quit Lars Ingebrigtsen
2021-06-03 16:54   ` Krzysztof Żelechowski
2021-06-06  9:16     ` Lars Ingebrigtsen
2021-06-06 11:58       ` Krzysztof Żelechowski
2021-06-06 12:50         ` Lars Ingebrigtsen
2021-06-06 12:59           ` Eli Zaretskii
2021-06-06 13:05             ` Lars Ingebrigtsen
2021-06-06 13:10               ` Eli Zaretskii
2021-06-08  9:36                 ` Lars Ingebrigtsen
2021-06-08 11:34                   ` Eli Zaretskii
2021-06-08 11:41                     ` Lars Ingebrigtsen
2021-06-06 13:04           ` Krzysztof Żelechowski
2021-06-06 13:12             ` Eli Zaretskii

unofficial mirror of bug-gnu-emacs@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-bugs/0 emacs-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-bugs emacs-bugs/ https://yhetil.org/emacs-bugs \
		bug-gnu-emacs@gnu.org
	public-inbox-index emacs-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.bugs
	nntp://news.gmane.io/gmane.emacs.bugs


code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git