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

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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 [hidden email]-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!



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Sam Steingold <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Sam Steingold
> * Eli Zaretskii <[hidden email]> [2012-04-27 22:01:27 +0300]:
>
>> From: Sam Steingold <[hidden email]>
>> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Sam Steingold <[hidden email]>
> Cc: [hidden email]
> Date: Fri, 27 Apr 2012 15:34:50 -0400
>
> > * Eli Zaretskii <[hidden email]> [2012-04-27 22:01:27 +0300]:
> >
> >> From: Sam Steingold <[hidden email]>
> >> 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.



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Sam Steingold
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Sam Steingold
On Sat, Apr 28, 2012 at 04:25, martin rudalics <[hidden email]> 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/>



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Sam Steingold
On Tue, May 1, 2012 at 04:09, martin rudalics <[hidden email]> 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/>



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by martin rudalics
> Date: Tue, 01 May 2012 10:09:01 +0200
> From: martin rudalics <[hidden email]>
> Cc: [hidden email]
>
>  >> 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.



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Sam Steingold
 > 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



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Eli Zaretskii
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Sam Steingold
In reply to this post by martin rudalics
> * martin rudalics <[hidden email]> [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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by martin rudalics
> Date: Wed, 02 May 2012 11:40:03 +0200
> From: martin rudalics <[hidden email]>
> CC: [hidden email], [hidden email]
>
>  > 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.



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Sam Steingold
 > 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

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

Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by martin rudalics
> Date: Sat, 05 May 2012 11:42:04 +0200
> From: martin rudalics <[hidden email]>
> CC: [hidden email], [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Sam Steingold
In reply to this post by martin rudalics
> * martin rudalics <[hidden email]> [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...



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Sam Steingold
Sam Steingold <[hidden email]> writes:

> On Tue, May 1, 2012 at 04:09, martin rudalics <[hidden email]> 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



12