* bug#11365: 24.1.50; quitting gdb does not restore window configuration
@ 2012-04-27 18:40 Sam Steingold
2012-04-27 19:01 ` Eli Zaretskii
2012-04-28 8:25 ` martin rudalics
0 siblings, 2 replies; 25+ messages in thread
From: Sam Steingold @ 2012-04-27 18:40 UTC (permalink / raw)
To: 11365
In GNU Emacs 24.1.50.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2012-04-27 on t520sds
Bzr revision: 108056 cyd@gnu.org-20120427141602-0ahy51h0haplvlr9
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
Configured using:
`configure '--with-wide-int''
quit in gdb now removes the gdb windows (which is very good! - except
that the *gud-lisp.run* buffer and window are preserved, which is not so
good) but it does not restore the window configuration which existed
when at M-x gdb RET time.
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://dhimmi.com http://honestreporting.com
http://www.memritv.org http://palestinefacts.org
I don't like cats! -- Come on, you just don't know how to cook them!
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-04-27 18:40 bug#11365: 24.1.50; quitting gdb does not restore window configuration Sam Steingold
@ 2012-04-27 19:01 ` Eli Zaretskii
2012-04-27 19:34 ` Sam Steingold
2012-04-28 8:25 ` martin rudalics
1 sibling, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-04-27 19:01 UTC (permalink / raw)
To: sds; +Cc: 11365
> From: Sam Steingold <sds@gnu.org>
> Date: Fri, 27 Apr 2012 14:40:07 -0400
>
> quit in gdb now removes the gdb windows (which is very good! - except
> that the *gud-lisp.run* buffer and window are preserved, which is not so
> good) but it does not restore the window configuration which existed
> when at M-x gdb RET time.
Did it ever do that? I don't see this in 23.3, for example.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-04-27 19:01 ` Eli Zaretskii
@ 2012-04-27 19:34 ` Sam Steingold
2012-04-28 6:51 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: Sam Steingold @ 2012-04-27 19:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11365
> * Eli Zaretskii <ryvm@tah.bet> [2012-04-27 22:01:27 +0300]:
>
>> From: Sam Steingold <sds@gnu.org>
>> Date: Fri, 27 Apr 2012 14:40:07 -0400
>>
>> quit in gdb now removes the gdb windows (which is very good! - except
>> that the *gud-lisp.run* buffer and window are preserved, which is not so
>> good) but it does not restore the window configuration which existed
>> when at M-x gdb RET time.
>
> Did it ever do that? I don't see this in 23.3, for example.
Until recently (see my bug#11273), quitting gdb did not change the
window configuration and preserved the stack, locals, &c windows and
buffers.
Now that was fixed and all those subsidiary buffers and windows are
killed.
however, the original window configuration is not restored, which is
wrong, and, also, the *gud* window is preserved, which is also wrong.
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://www.memritv.org http://memri.org
http://jihadwatch.org http://pmw.org.il http://iris.org.il http://dhimmi.com
Single tasking: Just Say No.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-04-27 19:34 ` Sam Steingold
@ 2012-04-28 6:51 ` Eli Zaretskii
0 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2012-04-28 6:51 UTC (permalink / raw)
To: sds; +Cc: 11365
> From: Sam Steingold <sds@gnu.org>
> Cc: 11365@debbugs.gnu.org
> Date: Fri, 27 Apr 2012 15:34:50 -0400
>
> > * Eli Zaretskii <ryvm@tah.bet> [2012-04-27 22:01:27 +0300]:
> >
> >> From: Sam Steingold <sds@gnu.org>
> >> Date: Fri, 27 Apr 2012 14:40:07 -0400
> >>
> >> quit in gdb now removes the gdb windows (which is very good! - except
> >> that the *gud-lisp.run* buffer and window are preserved, which is not so
> >> good) but it does not restore the window configuration which existed
> >> when at M-x gdb RET time.
> >
> > Did it ever do that? I don't see this in 23.3, for example.
>
> Until recently (see my bug#11273), quitting gdb did not change the
> window configuration and preserved the stack, locals, &c windows and
> buffers.
> Now that was fixed and all those subsidiary buffers and windows are
> killed.
>
> however, the original window configuration is not restored, which is
> wrong, and, also, the *gud* window is preserved, which is also wrong.
Then I guess you are requesting a new feature.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-04-27 18:40 bug#11365: 24.1.50; quitting gdb does not restore window configuration Sam Steingold
2012-04-27 19:01 ` Eli Zaretskii
@ 2012-04-28 8:25 ` martin rudalics
2012-04-30 22:14 ` Sam Steingold
1 sibling, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-04-28 8:25 UTC (permalink / raw)
To: sds; +Cc: 11365
> quit in gdb now removes the gdb windows (which is very good! - except
> that the *gud-lisp.run* buffer and window are preserved, which is not so
> good) but it does not restore the window configuration which existed
> when at M-x gdb RET time.
Which command does "quit" run - `gdb-delete-frame-or-window'?
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-04-28 8:25 ` martin rudalics
@ 2012-04-30 22:14 ` Sam Steingold
2012-05-01 8:09 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Sam Steingold @ 2012-04-30 22:14 UTC (permalink / raw)
To: martin rudalics; +Cc: 11365
On Sat, Apr 28, 2012 at 04:25, martin rudalics <rudalics@gmx.at> wrote:
>> quit in gdb now removes the gdb windows (which is very good! - except
>> that the *gud-lisp.run* buffer and window are preserved, which is not so
>> good) but it does not restore the window configuration which existed
>> when at M-x gdb RET time.
>
> Which command does "quit" run - `gdb-delete-frame-or-window'?
dunno. the code indicates that, but the function seems too simple to
remove all those subordinate windows and buffers.
--
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-04-30 22:14 ` Sam Steingold
@ 2012-05-01 8:09 ` martin rudalics
2012-05-01 12:25 ` Sam Steingold
2012-05-01 15:54 ` Eli Zaretskii
0 siblings, 2 replies; 25+ messages in thread
From: martin rudalics @ 2012-05-01 8:09 UTC (permalink / raw)
To: Sam Steingold; +Cc: 11365
>> Which command does "quit" run - `gdb-delete-frame-or-window'?
>
> dunno. the code indicates that, but the function seems too simple to
> remove all those subordinate windows and buffers.
So you have to check your key bindings ;-)
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-01 8:09 ` martin rudalics
@ 2012-05-01 12:25 ` Sam Steingold
2012-05-02 9:39 ` martin rudalics
2020-09-27 12:41 ` Lars Ingebrigtsen
2012-05-01 15:54 ` Eli Zaretskii
1 sibling, 2 replies; 25+ messages in thread
From: Sam Steingold @ 2012-05-01 12:25 UTC (permalink / raw)
To: martin rudalics; +Cc: 11365
On Tue, May 1, 2012 at 04:09, martin rudalics <rudalics@gmx.at> wrote:
>>> Which command does "quit" run - `gdb-delete-frame-or-window'?
>>
>> dunno. the code indicates that, but the function seems too simple to
>> remove all those subordinate windows and buffers.
>
> So you have to check your key bindings ;-)
I type "q u i t RET" in the *gud* buffer.
do you seriously think I rebind any of those keys?!
--
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-01 12:25 ` Sam Steingold
@ 2012-05-02 9:39 ` martin rudalics
2012-05-02 14:16 ` Sam Steingold
2020-09-27 12:41 ` Lars Ingebrigtsen
1 sibling, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-05-02 9:39 UTC (permalink / raw)
To: Sam Steingold; +Cc: 11365
> I type "q u i t RET" in the *gud* buffer.
> do you seriously think I rebind any of those keys?!
No. I was confused because you earlier said that quitting "now removes
the gdb windows" which is something gdb-mi always did here (at least
since Emacs 22). So I thought that you might use some specific command
to quit.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-02 9:39 ` martin rudalics
@ 2012-05-02 14:16 ` Sam Steingold
2012-05-05 9:42 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Sam Steingold @ 2012-05-02 14:16 UTC (permalink / raw)
To: martin rudalics; +Cc: 11365
> * martin rudalics <ehqnyvpf@tzk.ng> [2012-05-02 11:39:51 +0200]:
>
>> I type "q u i t RET" in the *gud* buffer.
>> do you seriously think I rebind any of those keys?!
>
> No. I was confused because you earlier said that quitting "now
> removes the gdb windows" which is something gdb-mi always did here (at
> least since Emacs 22). So I thought that you might use some specific
> command to quit.
This was not quite what I saw.
My experience was that the gdb windows hang around.
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11103000
http://www.childpsy.net/ http://ffii.org http://mideasttruth.com
http://www.memritv.org http://memri.org http://thereligionofpeace.com
Professionalism is being dispassionate about your work.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-02 14:16 ` Sam Steingold
@ 2012-05-05 9:42 ` martin rudalics
2012-05-06 5:40 ` Sam Steingold
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-05-05 9:42 UTC (permalink / raw)
To: sds; +Cc: 11365
[-- Attachment #1: Type: text/plain, Size: 155 bytes --]
> My experience was that the gdb windows hang around.
Even before bug#11273?
Anyway, what about calling `quit-window' as in the attached patch?
martin
[-- Attachment #2: gdb-mi.diff --]
[-- Type: text/plain, Size: 875 bytes --]
*** lisp/progmodes/gdb-mi.el 2012-04-25 08:07:57 +0000
--- lisp/progmodes/gdb-mi.el 2012-05-05 07:46:14 +0000
***************
*** 4187,4193 ****
(if (boundp 'speedbar-frame) (speedbar-timer-fn))
(setq gud-running nil)
(setq gdb-active-process nil)
! (remove-hook 'after-save-hook 'gdb-create-define-alist t))
(defun gdb-get-source-file ()
"Find the source file where the program starts and display it with related
--- 4187,4196 ----
(if (boundp 'speedbar-frame) (speedbar-timer-fn))
(setq gud-running nil)
(setq gdb-active-process nil)
! (remove-hook 'after-save-hook 'gdb-create-define-alist t)
! ;; Quit window of any *gud- buffer.
! (when (string-match "\\*gud-" (buffer-name (window-buffer)))
! (quit-window)))
(defun gdb-get-source-file ()
"Find the source file where the program starts and display it with related
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-05 9:42 ` martin rudalics
@ 2012-05-06 5:40 ` Sam Steingold
2012-05-06 10:25 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Sam Steingold @ 2012-05-06 5:40 UTC (permalink / raw)
To: martin rudalics; +Cc: 11365
> * martin rudalics <ehqnyvpf@tzk.ng> [2012-05-05 11:42:08 +0200]:
>
> ! (remove-hook 'after-save-hook 'gdb-create-define-alist t)
> ! ;; Quit window of any *gud- buffer.
> ! (when (string-match "\\*gud-" (buffer-name (window-buffer)))
> ! (quit-window)))
quit-window is not a solution, because it often kills the window.
I live in a maximized emacs frame which is split vertically in to two
columns, and an indiscriminate use of quit-window quickly destroys that.
In fact, I would like a feature which would make these two side-by-side
windows indestructible (i.e., prevent them from being destroyed other
than by an explicit interactive C-x 0). I guess I can set their
delete-window parameters to ignore but then
-1- C-x 0 will NOT delete them while
-2- any application which binds ignore-window-parameters to t will
delete them.
but I digress...
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11103000
http://www.childpsy.net/ http://americancensorship.org http://memri.org
http://www.PetitionOnline.com/tap12009/ http://thereligionofpeace.com
I'm out of my mind, but feel free to leave a message...
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-06 5:40 ` Sam Steingold
@ 2012-05-06 10:25 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2012-05-06 10:25 UTC (permalink / raw)
To: sds; +Cc: 11365
> quit-window is not a solution, because it often kills the window.
Only if it was specially created by `display-buffer' before.
> I live in a maximized emacs frame which is split vertically in to two
> columns, and an indiscriminate use of quit-window quickly destroys that.
This should not happen in the case at hand: The gud window is either
created or reused via `display-buffer'.
Anyway, we could provide a `quit-window-function' variable. Or maybe a
`display-buffer-record-window-function' which can set up the
quit-restore parameter in some way and, if the first element of the
quit-restore parameter is a function, have `quit-window' call that
function, passing it the cdr of the quit-restore parameter as argument.
> In fact, I would like a feature which would make these two side-by-side
> windows indestructible (i.e., prevent them from being destroyed other
> than by an explicit interactive C-x 0). I guess I can set their
> delete-window parameters to ignore but then
>
> -1- C-x 0 will NOT delete them while
You could set the `delete-window' parameter to some home-brewed function
that deletes the window for C-x 0 only. Probably, you then might have
to do something similar for C-x 1 ...
> -2- any application which binds ignore-window-parameters to t will
> delete them.
Applications binding `ignore-window-parameters' should know what they
are doing.
> but I digress...
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-01 12:25 ` Sam Steingold
2012-05-02 9:39 ` martin rudalics
@ 2020-09-27 12:41 ` Lars Ingebrigtsen
2020-09-27 12:56 ` Eli Zaretskii
1 sibling, 1 reply; 25+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-27 12:41 UTC (permalink / raw)
To: Sam Steingold; +Cc: 11365
Sam Steingold <sds@gnu.org> writes:
> On Tue, May 1, 2012 at 04:09, martin rudalics <rudalics@gmx.at> wrote:
>>>> Which command does "quit" run - `gdb-delete-frame-or-window'?
>>>
>>> dunno. the code indicates that, but the function seems too simple to
>>> remove all those subordinate windows and buffers.
>>
>> So you have to check your key bindings ;-)
>
> I type "q u i t RET" in the *gud* buffer.
> do you seriously think I rebind any of those keys?!
Reading this old bug report, it's not quite clear what the problem is --
mostly because there's no recipe to reproduce the issue.
If I do `M-x gdb RET quit RET' on src/emacs, the latter doesn't do
anything to any windows (and it would be confusing if it did).
Does anybody have a recipe here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2020-09-27 12:41 ` Lars Ingebrigtsen
@ 2020-09-27 12:56 ` Eli Zaretskii
2020-09-27 13:00 ` Lars Ingebrigtsen
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2020-09-27 12:56 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 11365, sds
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 27 Sep 2020 14:41:01 +0200
> Cc: 11365@debbugs.gnu.org
>
> Reading this old bug report, it's not quite clear what the problem is --
> mostly because there's no recipe to reproduce the issue.
>
> If I do `M-x gdb RET quit RET' on src/emacs, the latter doesn't do
> anything to any windows (and it would be confusing if it did).
The missing piece is "M-x gdb-many-windows RET", I think.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2020-09-27 12:56 ` Eli Zaretskii
@ 2020-09-27 13:00 ` Lars Ingebrigtsen
2020-09-27 13:02 ` Eli Zaretskii
2022-04-25 15:05 ` Lars Ingebrigtsen
0 siblings, 2 replies; 25+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-27 13:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11365, sds
Eli Zaretskii <eliz@gnu.org> writes:
> The missing piece is "M-x gdb-many-windows RET", I think.
Oh, wow. I've never been so shocked by something Emacs has done as the
window configuration Emacs popped up after `M-x gdb' after doing `M-x
gdb-many-windows'. :-)
Anyway, I can indeed reproduce the problem -- after saying "quit" in the
main gdb buffer, all the gdb buffers go away, but I'm left with a
two-window conf (and not the one-window conf I started out with).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2020-09-27 13:00 ` Lars Ingebrigtsen
@ 2020-09-27 13:02 ` Eli Zaretskii
2022-04-25 15:05 ` Lars Ingebrigtsen
1 sibling, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2020-09-27 13:02 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 11365, sds
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: sds@gnu.org, 11365@debbugs.gnu.org
> Date: Sun, 27 Sep 2020 15:00:51 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > The missing piece is "M-x gdb-many-windows RET", I think.
>
> Oh, wow. I've never been so shocked by something Emacs has done as the
> window configuration Emacs popped up after `M-x gdb' after doing `M-x
> gdb-many-windows'. :-)
Try debugging with this some time. It's really nice (IMO).
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2020-09-27 13:00 ` Lars Ingebrigtsen
2020-09-27 13:02 ` Eli Zaretskii
@ 2022-04-25 15:05 ` Lars Ingebrigtsen
2022-05-24 12:51 ` Lars Ingebrigtsen
1 sibling, 1 reply; 25+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-25 15:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11365, sds
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Anyway, I can indeed reproduce the problem -- after saying "quit" in the
> main gdb buffer, all the gdb buffers go away, but I'm left with a
> two-window conf (and not the one-window conf I started out with).
But I'm not sure whether we should do anything about this. The user may
have altered many things in the window conf between saying `M-x gdb'
(which pops up all those windows) and saying "quit" (which removes all
the popped-up windows).
Restoring a previous window configuration (which may, after all, include
killed buffers and other oddities) after exiting something like a gdb
session doesn't seem like something everybody'd want. But we could
offer it behind a user option, I guess.
Anybody got an opinion?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2022-04-25 15:05 ` Lars Ingebrigtsen
@ 2022-05-24 12:51 ` Lars Ingebrigtsen
0 siblings, 0 replies; 25+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-24 12:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11365, sds
Lars Ingebrigtsen <larsi@gnus.org> writes:
> But I'm not sure whether we should do anything about this. The user may
> have altered many things in the window conf between saying `M-x gdb'
> (which pops up all those windows) and saying "quit" (which removes all
> the popped-up windows).
>
> Restoring a previous window configuration (which may, after all, include
> killed buffers and other oddities) after exiting something like a gdb
> session doesn't seem like something everybody'd want. But we could
> offer it behind a user option, I guess.
>
> Anybody got an opinion?
Nobody had in a month, so I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-01 8:09 ` martin rudalics
2012-05-01 12:25 ` Sam Steingold
@ 2012-05-01 15:54 ` Eli Zaretskii
2012-05-02 9:40 ` martin rudalics
1 sibling, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-05-01 15:54 UTC (permalink / raw)
To: martin rudalics; +Cc: 11365, sds
> Date: Tue, 01 May 2012 10:09:01 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 11365@debbugs.gnu.org
>
> >> Which command does "quit" run - `gdb-delete-frame-or-window'?
> >
> > dunno. the code indicates that, but the function seems too simple to
> > remove all those subordinate windows and buffers.
>
> So you have to check your key bindings ;-)
No, he doesn't. The function to look at is gdb-reset.
(gdb-delete-frame-or-window is just what causes GDB to quit, but when
it actually does, the comint process sentinel kicks in and calls
gdb-reset.) But for gdb-reset to do what Sam wants, gdb-setup-windows
should record the configuration of windows before it sets up the GDB
windows, otherwise we will have no information about the previous
window configuration.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-01 15:54 ` Eli Zaretskii
@ 2012-05-02 9:40 ` martin rudalics
2012-05-02 16:02 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-05-02 9:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11365, sds
> The function to look at is gdb-reset.
> (gdb-delete-frame-or-window is just what causes GDB to quit, but when
> it actually does, the comint process sentinel kicks in and calls
> gdb-reset.) But for gdb-reset to do what Sam wants, gdb-setup-windows
> should record the configuration of windows before it sets up the GDB
> windows, otherwise we will have no information about the previous
> window configuration.
I fail to understand you. The window configuration *is* handled by
`gdb-delete-frame-or-window'. What should `gdb-reset' do about it and
when? IIUC Sam wants `gdb-delete-frame-or-window' restore a previous
configuration.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-02 9:40 ` martin rudalics
@ 2012-05-02 16:02 ` Eli Zaretskii
2012-05-05 9:42 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-05-02 16:02 UTC (permalink / raw)
To: martin rudalics; +Cc: 11365, sds
> Date: Wed, 02 May 2012 11:40:03 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: sds@gnu.org, 11365@debbugs.gnu.org
>
> > The function to look at is gdb-reset.
> > (gdb-delete-frame-or-window is just what causes GDB to quit, but when
> > it actually does, the comint process sentinel kicks in and calls
> > gdb-reset.) But for gdb-reset to do what Sam wants, gdb-setup-windows
> > should record the configuration of windows before it sets up the GDB
> > windows, otherwise we will have no information about the previous
> > window configuration.
>
> I fail to understand you. The window configuration *is* handled by
> `gdb-delete-frame-or-window'. What should `gdb-reset' do about it and
> when? IIUC Sam wants `gdb-delete-frame-or-window' restore a previous
> configuration.
It is IMO wrong to do what Sam wants in gdb-delete-frame-or-window.
That's because the restoration of the window configuration should be
done when GDB actually exits, not when the user _tells_ GDB to exit.
The function which handles the exit event is gdb-reset.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-02 16:02 ` Eli Zaretskii
@ 2012-05-05 9:42 ` martin rudalics
2012-05-05 9:49 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2012-05-05 9:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11365, sds
> It is IMO wrong to do what Sam wants in gdb-delete-frame-or-window.
`gdb-delete-frame-or-window' is completely unrelated to this discussion.
I was mislead by its binding to `quit' in `gdb-breakpoints-mode-map' and
the fact that it could delete a window or frame. Sorry for bringing it
in here in the first place.
> That's because the restoration of the window configuration should be
> done when GDB actually exits, not when the user _tells_ GDB to exit.
> The function which handles the exit event is gdb-reset.
Indeed. However, this presents a problem of orthogonality. We would
have to save the window configuration in `gud-common-init' (in gud.el)
and restore it in `gdb-reset' (in gdb-mi.el) which looks pretty ugly to
me. So `gud-common-init' would have to be aware of whether it's called
from `gdb' to avoid a leak. Note that every stored window configuration
uses up memory and causes overhead for maintaining markers.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-05 9:42 ` martin rudalics
@ 2012-05-05 9:49 ` Eli Zaretskii
2012-05-05 10:24 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2012-05-05 9:49 UTC (permalink / raw)
To: martin rudalics; +Cc: 11365, sds
> Date: Sat, 05 May 2012 11:42:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: sds@gnu.org, 11365@debbugs.gnu.org
>
> this presents a problem of orthogonality. We would have to save the
> window configuration in `gud-common-init' (in gud.el) and restore it
> in `gdb-reset' (in gdb-mi.el) which looks pretty ugly to me.
Why in gud-common-init? Why not in gdb-many-windows?
The other method of invoking GDB, gdb-gud, does not change the window
configuration in any significant way, and never restored window
configuration for as long as the old "M-x gdb" existed. So I think we
can limit this feature to gdb-many-windows, which _does_ change the
window configuration in dramatic ways.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#11365: 24.1.50; quitting gdb does not restore window configuration
2012-05-05 9:49 ` Eli Zaretskii
@ 2012-05-05 10:24 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2012-05-05 10:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11365, sds
> Why in gud-common-init? Why not in gdb-many-windows?
Because `gud-common-init' sets up the initial *gud- window. At the time
`gdb-many-windows' is called (if it is called at all) the knowledge
about any previous window buffer is lost because it got changed by
`gud-common-init'.
> The other method of invoking GDB, gdb-gud, does not change the window
> configuration in any significant way, and never restored window
> configuration for as long as the old "M-x gdb" existed.
Sam complained that
>> *gud-lisp.run* buffer and window are preserved
and that
>> it does not restore the window configuration which existed
>> when at M-x gdb RET time.
Your proposal would address neither of these.
> So I think we
> can limit this feature to gdb-many-windows, which _does_ change the
> window configuration in dramatic ways.
It does so, indeed.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2022-05-24 12:51 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-27 18:40 bug#11365: 24.1.50; quitting gdb does not restore window configuration Sam Steingold
2012-04-27 19:01 ` Eli Zaretskii
2012-04-27 19:34 ` Sam Steingold
2012-04-28 6:51 ` Eli Zaretskii
2012-04-28 8:25 ` martin rudalics
2012-04-30 22:14 ` Sam Steingold
2012-05-01 8:09 ` martin rudalics
2012-05-01 12:25 ` Sam Steingold
2012-05-02 9:39 ` martin rudalics
2012-05-02 14:16 ` Sam Steingold
2012-05-05 9:42 ` martin rudalics
2012-05-06 5:40 ` Sam Steingold
2012-05-06 10:25 ` martin rudalics
2020-09-27 12:41 ` Lars Ingebrigtsen
2020-09-27 12:56 ` Eli Zaretskii
2020-09-27 13:00 ` Lars Ingebrigtsen
2020-09-27 13:02 ` Eli Zaretskii
2022-04-25 15:05 ` Lars Ingebrigtsen
2022-05-24 12:51 ` Lars Ingebrigtsen
2012-05-01 15:54 ` Eli Zaretskii
2012-05-02 9:40 ` martin rudalics
2012-05-02 16:02 ` Eli Zaretskii
2012-05-05 9:42 ` martin rudalics
2012-05-05 9:49 ` Eli Zaretskii
2012-05-05 10:24 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).