bug#11365: 24.1.50; quitting gdb does not restore window configuration

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Sam Steingold]

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!

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Eli Zaretskii]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Sam Steingold]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Eli Zaretskii]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[martin rudalics]

 > 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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Sam Steingold]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[martin rudalics]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Sam Steingold]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Eli Zaretskii]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[martin rudalics]

 > 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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[martin rudalics]

 > 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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Sam Steingold]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Eli Zaretskii]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[martin rudalics]

 > 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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[martin rudalics]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Eli Zaretskii]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[martin rudalics]

 > 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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Sam Steingold]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[martin rudalics]

 > 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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Lars Ingebrigtsen]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Eli Zaretskii]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Lars Ingebrigtsen]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Eli Zaretskii]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Lars Ingebrigtsen]

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

bug#11365: 24.1.50; quitting gdb does not restore window configuration

[Lars Ingebrigtsen]

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