Use of dedicated windows in gdb-mi.el

Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Hi all,

I'm not happy with the current state of dedicated windows in gdb.  I saw
a discussion back from 2008 that kind of went nowhere.

Has the state-of-the-art in window placement improved since then?

In any case, could I add a custom variable to completely turn off
dedicated windows in gdb-mi.el? The current community workaround that I
found is to use commands that disregard dedicated windows in place of
the proper ones, just to play around gdb. I think it's better to just
give an option to turn dedicated windows off.

regards
Oleh

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Date: Fri, 06 Feb 2015 19:02:11 +0100
> 
> I'm not happy with the current state of dedicated windows in gdb.

Can you elaborate?

> In any case, could I add a custom variable to completely turn off
> dedicated windows in gdb-mi.el?

The default is not to display them, so I wonder how come you want them
turned off via defcustom.  What am I missing?

In any case, if you do want to turn them off, we already have a
command to do that: "M-x gdb-many-windows RET".

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Date: Fri, 06 Feb 2015 19:02:11 +0100
>> 
>> I'm not happy with the current state of dedicated windows in gdb.
>
> Can you elaborate?

For example:

1. `gdb' a C++ program
2. `gdb-many-windows'
3. switch to "*input/output of main*"
4. issue `ido-switch-buffer`

=> the buffer is switched in the "main.cc" window, although the point was in the
"*input/output of main*" window. I'm guessing that's because
"*input/output of main*" is dedicated. In fact, all of them are, except
the two that I actually want to see always: "main.cc" and "*gud-main*".

>> In any case, could I add a custom variable to completely turn off
>> dedicated windows in gdb-mi.el?
>
> The default is not to display them, so I wonder how come you want them
> turned off via defcustom.  What am I missing?
>
> In any case, if you do want to turn them off, we already have a
> command to do that: "M-x gdb-many-windows RET".

This doesn't work on 24.4.1.

Oleh

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 06 Feb 2015 20:14:40 +0100
> 
> 1. `gdb' a C++ program
> 2. `gdb-many-windows'
> 3. switch to "*input/output of main*"
> 4. issue `ido-switch-buffer`
> 
> => the buffer is switched in the "main.cc" window, although the point was in the
> "*input/output of main*" window. I'm guessing that's because
> "*input/output of main*" is dedicated. In fact, all of them are, except
> the two that I actually want to see always: "main.cc" and "*gud-main*".

I suggest calling ido-switch-buffer in another frame.

Re: Use of dedicated windows in gdb-mi.el

[Thibaut Verron]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> > From: Oleh Krehel <ohwoeowho <at> gmail.com>
> > Cc: emacs-devel <at> gnu.org
> > Date: Fri, 06 Feb 2015 20:14:40 +0100
> > 
> > 1. `gdb' a C++ program
> > 2. `gdb-many-windows'
> > 3. switch to "*input/output of main*"
> > 4. issue `ido-switch-buffer`
> > 
> > => the buffer is switched in the "main.cc" window, although the point was 
in the
> > "*input/output of main*" window. I'm guessing that's because
> > "*input/output of main*" is dedicated. In fact, all of them are, except
> > the two that I actually want to see always: "main.cc" and "*gud-main*".
> 
> I suggest calling ido-switch-buffer in another frame.
> 
> 

From what I understand, this work-around is an illustration of the point, 
rather than a solution: when someone presses C-x b, they want to change the 
buffer displayed in the current window. They do not want to have to switch to 
another window/frame before that, and they do not want to see the desired 
buffer appear in a random window.

Re: Use of dedicated windows in gdb-mi.el

[Stefan Monnier]

> From what I understand, this work-around is an illustration of the
> point, rather than a solution: when someone presses C-x b, they want
> to change the buffer displayed in the current window.  They do not
> want to have to switch to  another window/frame before that, and they
> do not want to see the desired  buffer appear in a random window.

I introduced "softly dedicated" windows for that kind of situation:
a "softly dedicated" window would not be chosen normally when Elisp code
wants to display some buffer somewhere, but if the user does `C-x b'
then the "soft dedication" gets overruled.

I know Martin doesn't like this concept, but in any case, if we could
try and arrange for gdb-mi to mark its windows as softly dedicated,
I think it would solve your use case.


        Stefan

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

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

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> From what I understand, this work-around is an illustration of the
>> point, rather than a solution: when someone presses C-x b, they want
>> to change the buffer displayed in the current window.  They do not
>> want to have to switch to  another window/frame before that, and they
>> do not want to see the desired  buffer appear in a random window.

Hi Stefan,

> I introduced "softly dedicated" windows for that kind of situation:
> a "softly dedicated" window would not be chosen normally when Elisp code
> wants to display some buffer somewhere, but if the user does `C-x b'
> then the "soft dedication" gets overruled.
>
> I know Martin doesn't like this concept, but in any case, if we could
> try and arrange for gdb-mi to mark its windows as softly dedicated,
> I think it would solve your use case.

Thanks, it solves it. Please see if the attached patch is OK.

Oleh


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gdb-mi.el-gdb-window-dedicated-flag-New-flag.patch --]
[-- Type: text/x-diff, Size: 1895 bytes --]

From e0b7210e4c9ad5c8175abe74f6f626d850472d00 Mon Sep 17 00:00:00 2001
From: Oleh Krehel <ohwoeowho@gmail.com>
Date: Mon, 9 Feb 2015 15:45:00 +0100
Subject: [PATCH] gdb-mi.el (gdb-window-dedicated-flag): New flag

* lisp/progmodes/gdb-mi.el (gdb-window-dedicated-flag): This flag is
  passed to `set-window-dedicated-p' each time it needs to be called
  with a non-nil flag.
(gdb-display-buffer): Update.
(gdb-set-window-buffer): Update.
---
 lisp/progmodes/gdb-mi.el | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/gdb-mi.el b/lisp/progmodes/gdb-mi.el
index 27846ed..48f0cd2 100644
--- a/lisp/progmodes/gdb-mi.el
+++ b/lisp/progmodes/gdb-mi.el
@@ -252,6 +252,14 @@ lower token-number are out-of-order."
   :group 'gud
   :version "24.4")
 
+(defcustom gdb-window-dedicated-flag t
+  "Non-nil flag used for calls to `set-window-dedicated-p'."
+  :type '(choice
+          (const :tag "Plain" t)
+          (const :tag "Soft" soft))
+  :group 'gud
+  :version "25.1")
+
 (cl-defstruct gdb-handler
   "Data required to handle the reply of a command sent to GDB."
   ;; Prefix of the command sent to GDB.  The GDB reply for this command
@@ -4282,7 +4290,7 @@ overlay arrow in source buffer."
 (defun gdb-display-buffer (buf)
   "Show buffer BUF, and make that window dedicated."
   (let ((window (display-buffer buf)))
-    (set-window-dedicated-p window t)
+    (set-window-dedicated-p window gdb-window-dedicated-flag)
     window))
 
   ;; (let ((answer (get-buffer-window buf 0)))
@@ -4447,7 +4455,7 @@ window is dedicated."
   (when ignore-dedicated
     (set-window-dedicated-p window nil))
   (set-window-buffer window (get-buffer name))
-  (set-window-dedicated-p window t))
+  (set-window-dedicated-p window gdb-window-dedicated-flag))
 
 (defun gdb-setup-windows ()
   "Layout the window pattern for option `gdb-many-windows'."
-- 
1.8.4

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Mon, 9 Feb 2015 09:19:48 +0000 (UTC)
> 
> > > From: Oleh Krehel <ohwoeowho <at> gmail.com>
> > > Cc: emacs-devel <at> gnu.org
> > > Date: Fri, 06 Feb 2015 20:14:40 +0100
> > > 
> > > 1. `gdb' a C++ program
> > > 2. `gdb-many-windows'
> > > 3. switch to "*input/output of main*"
> > > 4. issue `ido-switch-buffer`
> > > 
> > > => the buffer is switched in the "main.cc" window, although the point was 
> in the
> > > "*input/output of main*" window. I'm guessing that's because
> > > "*input/output of main*" is dedicated. In fact, all of them are, except
> > > the two that I actually want to see always: "main.cc" and "*gud-main*".
> > 
> > I suggest calling ido-switch-buffer in another frame.

> From what I understand, this work-around is an illustration of the point, 
> rather than a solution:

It depends on your POV, I guess.

> when someone presses C-x b, they want to change the buffer displayed
> in the current window. They do not want to have to switch to another
> window/frame before that, and they do not want to see the desired
> buffer appear in a random window.

The dedicated windows are an explicit _feature_ of GDB-MI.  GDB-MI
attempts to provide a faithful emulation of an IDE-like debugging
environment, where the source is browsed and edited in the source
window, I/O is in the input-output window, registers and breakpoints
in their specialized windows, etc.  What you describe above is the
consequence of that feature.

If you don't like this fixed arrangement of dedicated windows, then
why are you using GDB-MI?  Simply either turn off "the other" windows,
or don't turn them on in the first place (they are disabled by
default).  Then you will have full freedom of selecting which buffer
gets displayed in what window, as usual in Emacs.

My suggestion to use another frame was meant to give you the best of
all worlds -- the ability to switch to any buffer you like without
losing the IDE-like behavior of GDB-MI.  I don't really understand the
nature of your objection to it: doesn't it resolve the dilemma?

IOW, I don't understand why would anyone want GDB-MI, but without its
predefined arrangement of windows.  If we lift the dedicated windows
limitation, Emacs will pop the GDB-MI buffers all over the place, as
you well know.  Why does it make sense to "hunt" for a certain GDB-MI
buffer, like the call-stack buffer, when you can't even remember its
name easily?

Can you explain the motivation, and also why using GDB without the
other windows is not an option?

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 09 Feb 2015 09:29:34 -0500
> Cc: emacs-devel@gnu.org
> 
> I know Martin doesn't like this concept, but in any case, if we could
> try and arrange for gdb-mi to mark its windows as softly dedicated,
> I think it would solve your use case.

I'd like to hear the motivation first, because doing so goes against
the whole design of gdb-mi.  It makes little sense to me to have a
package that provides certain features as inherent part of its design,
only to disable those features on a whim.  Users who don't like the
gdb-mi UI can simply refrain from displaying those windows, they
aren't displayed by default.

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

> If you don't like this fixed arrangement of dedicated windows, then
> why are you using GDB-MI?  Simply either turn off "the other" windows,
> or don't turn them on in the first place (they are disabled by
> default).  Then you will have full freedom of selecting which buffer
> gets displayed in what window, as usual in Emacs.
>
> My suggestion to use another frame was meant to give you the best of
> all worlds -- the ability to switch to any buffer you like without
> losing the IDE-like behavior of GDB-MI.  I don't really understand the
> nature of your objection to it: doesn't it resolve the dilemma?
>
> IOW, I don't understand why would anyone want GDB-MI, but without its
> predefined arrangement of windows.  If we lift the dedicated windows
> limitation, Emacs will pop the GDB-MI buffers all over the place, as
> you well know.  Why does it make sense to "hunt" for a certain GDB-MI
> buffer, like the call-stack buffer, when you can't even remember its
> name easily?
>
> Can you explain the motivation, and also why using GDB without the
> other windows is not an option?

I'm using plain `gdb', I don't even like `gdb-many-windows'. But even in
plain `gdb', I'm getting a dedicated *output* window that pops up each
time there's output. This *output* window is hard to get rid of: even if
I kill that buffer, it comes back, dedicated once more.

The patch that I attached solves my problem with plain `gdb'.

Oleh

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: Thibaut Verron <thibaut.verron@gmail.com>,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 16:57:36 +0100
> 
> I'm using plain `gdb', I don't even like `gdb-many-windows'. But even in
> plain `gdb', I'm getting a dedicated *output* window that pops up each
> time there's output.

Don't you _want_ to see the output of a program you are debugging?

And I still don't understand why you must switch buffers in that
specific window.

> The patch that I attached solves my problem with plain `gdb'.

Maybe I'm missing something, but it looked to me that it made _all_
the gdb-mi windows soft-dedicated.  If that's true, how about making
only the popping output window soft-dedicated instead?

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: Thibaut Verron <thibaut.verron@gmail.com>,  emacs-devel@gnu.org
>> Date: Mon, 09 Feb 2015 16:57:36 +0100
>> 
>> I'm using plain `gdb', I don't even like `gdb-many-windows'. But even in
>> plain `gdb', I'm getting a dedicated *output* window that pops up each
>> time there's output.
>
> Don't you _want_ to see the output of a program you are debugging?

Nope. I can see all that I need through "p". The actual program output
for my particular program is barely relevant during runtime, and completely
irrelevant during debug time.

> And I still don't understand why you must switch buffers in that
> specific window.

Because I _don't want_ to see a window that I don't want to see,
*output* in this case. I like to have complete control over all my Emacs
windows at all time, with no irrelevant windows to annoy me.

>> The patch that I attached solves my problem with plain `gdb'.
>
> Maybe I'm missing something, but it looked to me that it made _all_
> the gdb-mi windows soft-dedicated.  If that's true, how about making
> only the popping output window soft-dedicated instead?

It changed two calls to `set-window-dedicated-p` to use the new custom
var, which is still t by default. Why should this worry you? I can set
the flag to 'soft, and you can keep it t.

Oleh

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: thibaut.verron@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 18:22:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Oleh Krehel <ohwoeowho@gmail.com>
> >> Cc: Thibaut Verron <thibaut.verron@gmail.com>,  emacs-devel@gnu.org
> >> Date: Mon, 09 Feb 2015 16:57:36 +0100
> >> 
> >> I'm using plain `gdb', I don't even like `gdb-many-windows'. But even in
> >> plain `gdb', I'm getting a dedicated *output* window that pops up each
> >> time there's output.
> >
> > Don't you _want_ to see the output of a program you are debugging?
> 
> Nope. I can see all that I need through "p". The actual program output
> for my particular program is barely relevant during runtime, and completely
> irrelevant during debug time.

Then perhaps a better solution would be an option not to pop the
*output* window at all, so that the need to switch to another buffer
in that window is eliminated?  Would you like such a solution better?

> >> The patch that I attached solves my problem with plain `gdb'.
> >
> > Maybe I'm missing something, but it looked to me that it made _all_
> > the gdb-mi windows soft-dedicated.  If that's true, how about making
> > only the popping output window soft-dedicated instead?
> 
> It changed two calls to `set-window-dedicated-p` to use the new custom
> var, which is still t by default. Why should this worry you?

Because that changes behavior of all the other GDB-MI windows, which
are not part of the original problem in any way, as they are not
displayed unless the user asked for them.  If what bothers you is that
the *output* window pops up when you don't want to see it, I think
it's better to solve that specific problem without affecting any
unrelated features.

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: thibaut.verron@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 09 Feb 2015 18:22:25 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Oleh Krehel <ohwoeowho@gmail.com>
>> >> Cc: Thibaut Verron <thibaut.verron@gmail.com>,  emacs-devel@gnu.org
>> >> Date: Mon, 09 Feb 2015 16:57:36 +0100
>> >> 
>> >> I'm using plain `gdb', I don't even like `gdb-many-windows'. But even in
>> >> plain `gdb', I'm getting a dedicated *output* window that pops up each
>> >> time there's output.
>> >
>> > Don't you _want_ to see the output of a program you are debugging?
>> 
>> Nope. I can see all that I need through "p". The actual program output
>> for my particular program is barely relevant during runtime, and completely
>> irrelevant during debug time.
>
> Then perhaps a better solution would be an option not to pop the
> *output* window at all, so that the need to switch to another buffer
> in that window is eliminated?  Would you like such a solution better?

No this won't work. I don't want *output* in this particular program. I
might want it for others. I just want the typical approach of burying a
buffer once and then having it not surface, even if there's new output.

Just imagine the havoc of *Messages* being a dedicated window and
popping up each time there's a new message, even if you bury it.

>> >> The patch that I attached solves my problem with plain `gdb'.
>> >
>> > Maybe I'm missing something, but it looked to me that it made _all_
>> > the gdb-mi windows soft-dedicated.  If that's true, how about making
>> > only the popping output window soft-dedicated instead?
>> 
>> It changed two calls to `set-window-dedicated-p` to use the new custom
>> var, which is still t by default. Why should this worry you?
>
> Because that changes behavior of all the other GDB-MI windows, which
> are not part of the original problem in any way, as they are not
> displayed unless the user asked for them.  If what bothers you is that
> the *output* window pops up when you don't want to see it, I think
> it's better to solve that specific problem without affecting any
> unrelated features.

I dislike non-soft dedicated windows because they're bad design. I guess
that I could just advice `set-window-dedicated-p' to be a noop in all
cases.

If you have 9 minutes and a way to view Youtube videos, you can see my
demo of a neat approach to manipulating windows (especially the window
swap). This approach of course won't work with non-soft dedicated
windows: https://www.youtube.com/watch?v=_qZliI1BKzI.

Oleh

RE: Use of dedicated windows in gdb-mi.el

[Drew Adams]

> Just imagine the havoc of *Messages* being a dedicated window and
> popping up each time there's a new message, even if you bury it.

FWIW, I use a dedicated window and separate frame for *Messages*.
And no, it doesn't pop up each time there's a new message.

> I dislike non-soft dedicated windows because they're bad design. 

What's the bad design about having such a possibility?

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Drew Adams <drew.adams@oracle.com> writes:

>> I dislike non-soft dedicated windows because they're bad design. 
>
> What's the bad design about having such a possibility?

You have a window. You switched to it explicitly. You want to change the
buffer that's in it, but you can't.

To top it off, it looks exactly the same all the other windows, 99.5% of
which that don't behave this way.

Add even on top that it wasn't you who explicitly specified this
behavior for your window. This behavior was simply loaded from a
package.

Re: Use of dedicated windows in gdb-mi.el

[martin rudalics]

 > I know Martin doesn't like this concept, but in any case, if we could
 > try and arrange for gdb-mi to mark its windows as softly dedicated,
 > I think it would solve your use case.

On Thu, 06 May 2010 10:22:11 +0200 I tried to answer you as follows:

 > > I know you think dedicated windows suck and that I like them so much
 > > that "when you have a hammer everything looks like a nail", but I think
 > > this is really a good case to mark the window dedicated.  I'm not sure
 > > whether set-window-configuration would do the right thing currently
 > > (kill the window if the buffer died), but if it doesn't, it'd be
 > > a clear bug that needs fixing.
 >
 > I don't think that dedicated windows suck and even went so far as to
 > give them an entire section in the Elisp manual ;-)
 >
 > On the average, 50% of my windows are dedicated and they suit my needs
 > well.  So I think that hardly anyone out there uses dedicated windows
 > more than me.

And if you look at `window-preserve-size' you may observe that it's a
"soft" variant of fixed-size windows.  So I even adopted your concept in
a different context ;-)

martin

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: thibaut.verron@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 19:11:27 +0100
> 
> >> > Don't you _want_ to see the output of a program you are debugging?
> >> 
> >> Nope. I can see all that I need through "p". The actual program output
> >> for my particular program is barely relevant during runtime, and completely
> >> irrelevant during debug time.
> >
> > Then perhaps a better solution would be an option not to pop the
> > *output* window at all, so that the need to switch to another buffer
> > in that window is eliminated?  Would you like such a solution better?
> 
> No this won't work. I don't want *output* in this particular program. I
> might want it for others.

If the option not to pop it is a defcustom, you can turn it on when
you want *output* and off when you don't.

> I just want the typical approach of burying a buffer once and then
> having it not surface, even if there's new output.

The option not to pop it in a window will solve this as well, right?

> Just imagine the havoc of *Messages* being a dedicated window and
> popping up each time there's a new message, even if you bury it.

JFYI, there are people who like to configure Emacs like that.  You've
just heard from one of them.  To each their own.

> I dislike non-soft dedicated windows because they're bad design.

Others will disagree.  gdb-many-windows is for them; if you don't like
that, it's very easy not to request those windows.

> I guess that I could just advice `set-window-dedicated-p' to be a
> noop in all cases.

If that's what you prefer.  I still think that an option to pop or not
to pop the *output* window, which is the only one that opens without
your say-so, is a better solution.  It gives you what you want without
affecting unrelated features and other users.

> If you have 9 minutes and a way to view Youtube videos, you can see my
> demo of a neat approach to manipulating windows (especially the window
> swap). This approach of course won't work with non-soft dedicated
> windows: https://www.youtube.com/watch?v=_qZliI1BKzI.

That's cute, but is this related to GDB-MI and the issue being
discussed here?  If so, how?

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: thibaut.verron@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 09 Feb 2015 19:11:27 +0100
>> 
>> >> > Don't you _want_ to see the output of a program you are debugging?
>> >> 
>> >> Nope. I can see all that I need through "p". The actual program output
>> >> for my particular program is barely relevant during runtime, and completely
>> >> irrelevant during debug time.
>> >
>> > Then perhaps a better solution would be an option not to pop the
>> > *output* window at all, so that the need to switch to another buffer
>> > in that window is eliminated?  Would you like such a solution better?
>> 
>> No this won't work. I don't want *output* in this particular program. I
>> might want it for others.
>
> If the option not to pop it is a defcustom, you can turn it on when
> you want *output* and off when you don't.

>> I just want the typical approach of burying a buffer once and then
>> having it not surface, even if there's new output.
>
> The option not to pop it in a window will solve this as well, right?

A per-project custom variable is better than nothing, although much
worse than an option of setting a window that has no business being
dedicated to soft-dedicated.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  thibaut.verron@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 19:39:04 +0100
> 
> To top it off, it looks exactly the same all the other windows, 99.5% of
> which that don't behave this way.

So maybe we should have some clear indication of the fact that a
window is dedicated.  Would you like to work on that?

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> If you have 9 minutes and a way to view Youtube videos, you can see my
>> demo of a neat approach to manipulating windows (especially the window
>> swap). This approach of course won't work with non-soft dedicated
>> windows: https://www.youtube.com/watch?v=_qZliI1BKzI.
>
> That's cute, but is this related to GDB-MI and the issue being
> discussed here?  If so, how?

There's a function that swaps the current window with the selected one.
It fails miserably with dedicated windows, although works with
soft-dedicated.

The point is that the user may know better how to manipulate the window
layout. Random dedicated windows that behave differently from normal windows,
without a visual indication that they are different, aren't a good design.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: thibaut.verron@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 19:58:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> If you have 9 minutes and a way to view Youtube videos, you can see my
> >> demo of a neat approach to manipulating windows (especially the window
> >> swap). This approach of course won't work with non-soft dedicated
> >> windows: https://www.youtube.com/watch?v=_qZliI1BKzI.
> >
> > That's cute, but is this related to GDB-MI and the issue being
> > discussed here?  If so, how?
> 
> There's a function that swaps the current window with the selected one.
> It fails miserably with dedicated windows, although works with
> soft-dedicated.

So maybe we should have a way to override the window's dedicated
status, with a special command or an argument to a command or a
variable.

> The point is that the user may know better how to manipulate the window
> layout. Random dedicated windows that behave differently from normal windows,
> without a visual indication that they are different, aren't a good design.

You need to see the GDB-MI design as a whole.  You are entitled to
your opinions about its design, but it is consistent, and many users
like it, probably because they come from other IDEs (where all windows
are dedicated).

RE: Use of dedicated windows in gdb-mi.el

[Drew Adams]

> >> I dislike non-soft dedicated windows because they're bad design.
> >
> > What's the bad design about having such a possibility?
> 
> You have a window. You switched to it explicitly. You want to change the
> buffer that's in it, but you can't.

If you want to change the buffer that's in the window, then you don't
want a (normally) dedicated window.

That doesn't imply bad design.  It just says that you did something
(made the window dedicated) that you didn't want to do.  You shot
yourself in the foot.  That's just bad aim on the part of the pilot.

> To top it off, it looks exactly the same all the other windows, 99.5% of
> which that don't behave this way.

Not for me, it doesn't.  I use options `special-display-frame-alist',
`special-display-buffer-names', and `special-display-regexps'.

*Messages* corresponds to my value of `special-display-regexps', which
is ("[ ]?[*][^*]+[*]").  As such, it gets a different background color
from my non-special frames.

> Add even on top that it wasn't you who explicitly specified this
> behavior for your window. This behavior was simply loaded from a
> package.

Blame that one on the package.  If that's true, and it that behavior
is hard-coded and not user-configurable, then THAT is bad design.

IMHO.

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: thibaut.verron@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 09 Feb 2015 19:58:19 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> If you have 9 minutes and a way to view Youtube videos, you can see my
>> >> demo of a neat approach to manipulating windows (especially the window
>> >> swap). This approach of course won't work with non-soft dedicated
>> >> windows: https://www.youtube.com/watch?v=_qZliI1BKzI.
>> >
>> > That's cute, but is this related to GDB-MI and the issue being
>> > discussed here?  If so, how?
>> 
>> There's a function that swaps the current window with the selected one.
>> It fails miserably with dedicated windows, although works with
>> soft-dedicated.
>
> So maybe we should have a way to override the window's dedicated
> status, with a special command or an argument to a command or a
> variable.

This would be useful, since other IDEs (at least QT Creator, probably
Eclipse) certainly have more options for dealing with dedicated windows.
For instance, QT Creator has a drop-down-style switch-buffer attached to
each dedicated window. You can select appropriate buffers for that
window.

Same this could/should work for `gdb-many-windows': for instance, I
could swap *locals* and *output* because *output* window is larger and I
care more about *locals*.

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  thibaut.verron@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 09 Feb 2015 19:39:04 +0100
>> 
>> To top it off, it looks exactly the same all the other windows, 99.5% of
>> which that don't behave this way.
>
> So maybe we should have some clear indication of the fact that a
> window is dedicated.  Would you like to work on that?

No, thanks.

    (defadvice set-window-dedicated-p (around no-dedicated-windows activate))

Problem solved:)

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Drew Adams <drew.adams@oracle.com> writes:

>> >> I dislike non-soft dedicated windows because they're bad design.
>> >
>> > What's the bad design about having such a possibility?
>> 
>> You have a window. You switched to it explicitly. You want to change the
>> buffer that's in it, but you can't.
>
> If you want to change the buffer that's in the window, then you don't
> want a (normally) dedicated window.
>
> That doesn't imply bad design.  It just says that you did something
> (made the window dedicated) that you didn't want to do.  You shot
> yourself in the foot.  That's just bad aim on the part of the pilot.

I just issued "r" in `gdb', nothing else. Zero customizations and a
dedicated *output* popped up.

>
>> To top it off, it looks exactly the same all the other windows, 99.5% of
>> which that don't behave this way.
>
> Not for me, it doesn't.  I use options `special-display-frame-alist',
> `special-display-buffer-names', and `special-display-regexps'.
>
> *Messages* corresponds to my value of `special-display-regexps', which
> is ("[ ]?[*][^*]+[*]").  As such, it gets a different background color
> from my non-special frames.
>
>> Add even on top that it wasn't you who explicitly specified this
>> behavior for your window. This behavior was simply loaded from a
>> package.
>
> Blame that one on the package.  If that's true, and it that behavior
> is hard-coded and not user-configurable, then THAT is bad design.

The patch earlier in the thread attempts to make it user-configurable
instead of hard-coded.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Date: Mon, 09 Feb 2015 20:48:13 +0100
> Cc: drew.adams@oracle.com, thibaut.verron@gmail.com, emacs-devel@gnu.org
> 
>     (defadvice set-window-dedicated-p (around no-dedicated-windows activate))
> 
> Problem solved:)

For you, but not for others.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  thibaut.verron@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 20:50:04 +0100
> 
> I just issued "r" in `gdb', nothing else. Zero customizations and a
> dedicated *output* popped up.

I proposed to add a defcustom to prevent that.  I still think it would
be a good solution, at least for popping window.

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  thibaut.verron@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 09 Feb 2015 20:50:04 +0100
>> 
>> I just issued "r" in `gdb', nothing else. Zero customizations and a
>> dedicated *output* popped up.
>
> I proposed to add a defcustom to prevent that.  I still think it would
> be a good solution, at least for popping window.

You're right, the dedicated window business was only a small part of the
problem.  The output window still pops up each time there's new output.

So even if I switch to *scratch* in the window of *output*, which I can
now do thanks to an advice, *output* will still pop up when something
new is printed by the program. So this defcustom would really be handy.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: thibaut.verron@gmail.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 21:09:34 +0100
> 
> > I proposed to add a defcustom to prevent that.  I still think it would
> > be a good solution, at least for popping window.
> 
> You're right, the dedicated window business was only a small part of the
> problem.  The output window still pops up each time there's new output.
> 
> So even if I switch to *scratch* in the window of *output*, which I can
> now do thanks to an advice, *output* will still pop up when something
> new is printed by the program. So this defcustom would really be handy.

AFAICS, it's a simple matter of adding a defcustom to be tested in
gdb-display-io-buffer, causing the latter do nothing if the user says
so.

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: thibaut.verron@gmail.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Mon, 09 Feb 2015 21:09:34 +0100
>> 
>> > I proposed to add a defcustom to prevent that.  I still think it would
>> > be a good solution, at least for popping window.
>> 
>> You're right, the dedicated window business was only a small part of the
>> problem.  The output window still pops up each time there's new output.
>> 
>> So even if I switch to *scratch* in the window of *output*, which I can
>> now do thanks to an advice, *output* will still pop up when something
>> new is printed by the program. So this defcustom would really be handy.
>
> AFAICS, it's a simple matter of adding a defcustom to be tested in
> gdb-display-io-buffer, causing the latter do nothing if the user says
> so.

Just instrumented `gdb-display-io-buffer', it's not the function that
makes the *output* buffer pop up when there's new output.

RE: Use of dedicated windows in gdb-mi.el

[Drew Adams]

> > Just imagine the havoc of *Messages* being a dedicated window and
> > popping up each time there's a new message, even if you bury it.
> 
> JFYI, there are people who like to configure Emacs like that.  You've
> just heard from one of them.  To each their own.

I'm guessing that you are referring to my reply?  If so, let me
repeat that *Messages* does not pop up each time there's a new
message.  In fact, it never pops up.  Unless I pop it up, on
purpose.  Calls to `message' do not pop up *Messages*, whether
or not it is shown in a dedicated window when it is shown.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Date: Mon, 09 Feb 2015 21:33:36 +0100
> Cc: thibaut.verron@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org
> 
> > AFAICS, it's a simple matter of adding a defcustom to be tested in
> > gdb-display-io-buffer, causing the latter do nothing if the user says
> > so.
> 
> Just instrumented `gdb-display-io-buffer', it's not the function that
> makes the *output* buffer pop up when there's new output.

Perhaps gdb-inferior-filter, then?

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Date: Mon, 09 Feb 2015 21:33:36 +0100
>> Cc: thibaut.verron@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org
>> 
>> > AFAICS, it's a simple matter of adding a defcustom to be tested in
>> > gdb-display-io-buffer, causing the latter do nothing if the user says
>> > so.
>> 
>> Just instrumented `gdb-display-io-buffer', it's not the function that
>> makes the *output* buffer pop up when there's new output.
>
> Perhaps gdb-inferior-filter, then?

That's it. Here's the patch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gdb-mi.el-gdb-display-io-nopopup-New-defcustom.patch --]
[-- Type: text/x-diff, Size: 1497 bytes --]

From b77380d3690fcc1ac032227df29734648874d48c Mon Sep 17 00:00:00 2001
From: Oleh Krehel <ohwoeowho@gmail.com>
Date: Mon, 9 Feb 2015 21:43:37 +0100
Subject: [PATCH] gdb-mi.el (gdb-display-io-nopopup): New defcustom

* lisp/progmodes/gdb-mi.el (gdb-inferior-filter): When
  `gdb-display-io-nopopup' is t, and the output buffer is already
  buried, don't pop it up.
---
 lisp/progmodes/gdb-mi.el | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/gdb-mi.el b/lisp/progmodes/gdb-mi.el
index 27846ed..2233caa 100644
--- a/lisp/progmodes/gdb-mi.el
+++ b/lisp/progmodes/gdb-mi.el
@@ -1629,9 +1629,19 @@ this trigger is subscribed to `gdb-buf-publisher' and called with
   :syntax-table nil :abbrev-table nil
   (make-comint-in-buffer "gdb-inferior" (current-buffer) nil))
 
+(defcustom gdb-display-io-nopopup nil
+  "When t, and the `gdb-inferior-io' buffer is buried, don't pop it up."
+  :type 'boolean
+  :group 'gdb
+  :version "25.1")
+
 (defun gdb-inferior-filter (proc string)
   (unless (string-equal string "")
-    (gdb-display-buffer (gdb-get-buffer-create 'gdb-inferior-io)))
+    (let (buf)
+      (unless (and (setq buf (gdb-get-buffer 'gdb-inferior-io))
+                   (null (get-buffer-window buf))
+                   gdb-display-io-nopopup)
+        (gdb-display-buffer (gdb-get-buffer-create 'gdb-inferior-io)))))
   (with-current-buffer (gdb-get-buffer-create 'gdb-inferior-io)
     (comint-output-filter proc string)))
 
-- 
1.8.4

Re: Use of dedicated windows in gdb-mi.el

[Barry OReilly]

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

> The dedicated windows are an explicit _feature_ of GDB-MI. GDB-MI
> attempts to provide a faithful emulation of an IDE-like debugging
> environment, where the source is browsed and edited in the source
> window, I/O is in the input-output window, registers and breakpoints
> in their specialized windows, etc. What you describe above is the
> consequence of that feature.

gdb-mi is buggy and the usability is poor. Anecdotally, the most
common Emacs FAQ I encounter is about gdb and the user is always
satisfied once pointed to gud-gdb. The "gdb" command ought to invoke
what "gud-gdb" does today.

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

Re: Use of dedicated windows in gdb-mi.el

[Stefan Monnier]

> The patch earlier in the thread attempts to make it user-configurable
> instead of hard-coded.

BTW, feel free to install it,


        Stefan "who likes soft-dedication"

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Drew Adams <drew.adams@oracle.com>,  Eli Zaretskii <eliz@gnu.org>,  thibaut.verron@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 21:20:43 -0500
> 
> > The patch earlier in the thread attempts to make it user-configurable
> > instead of hard-coded.
> 
> BTW, feel free to install it,

No, please don't.

>         Stefan "who likes soft-dedication"

          Eli "who dislikes his opinions ignored"

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii
>> <eliz@gnu.org>, thibaut.verron@gmail.com, emacs-devel@gnu.org
>> Date: Mon, 09 Feb 2015 21:20:43 -0500
>> 
>> > The patch earlier in the thread attempts to make it user-configurable
>> > instead of hard-coded.
>> 
>> BTW, feel free to install it,
>
> No, please don't.
>
>>         Stefan "who likes soft-dedication"
>
>           Eli "who dislikes his opinions ignored"

What about the other patch with `gdb-display-io-nopopup'?

    Oleh "who likes to play nice while making progress"

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: drew.adams@oracle.com,  thibaut.verron@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 09 Feb 2015 21:46:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Oleh Krehel <ohwoeowho@gmail.com>
> >> Date: Mon, 09 Feb 2015 21:33:36 +0100
> >> Cc: thibaut.verron@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org
> >> 
> >> > AFAICS, it's a simple matter of adding a defcustom to be tested in
> >> > gdb-display-io-buffer, causing the latter do nothing if the user says
> >> > so.
> >> 
> >> Just instrumented `gdb-display-io-buffer', it's not the function that
> >> makes the *output* buffer pop up when there's new output.
> >
> > Perhaps gdb-inferior-filter, then?
> 
> That's it. Here's the patch.

Thanks, this looks good to me.  I suggest to wait for a couple of
days, to give others time to comment, and if there are no objectsions,
please push it then.

> +(defcustom gdb-display-io-nopopup nil
> +  "When t, and the `gdb-inferior-io' buffer is buried, don't pop it up."

"When non-nil, and ..." is more accurate, since the code doesn't
really require t.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  thibaut.verron@gmail.com,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Tue, 10 Feb 2015 07:39:48 +0100
> 
> What about the other patch with `gdb-display-io-nopopup'?
> 
>     Oleh "who likes to play nice while making progress"

It's fine with me, see my other mail.

Thanks.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> Date: Mon, 9 Feb 2015 16:49:43 -0800
> From: Barry OReilly <gundaetiapo@gmail.com>
> 
> > The dedicated windows are an explicit _feature_ of GDB-MI. GDB-MI
> > attempts to provide a faithful emulation of an IDE-like debugging
> > environment, where the source is browsed and edited in the source
> > window, I/O is in the input-output window, registers and breakpoints
> > in their specialized windows, etc. What you describe above is the
> > consequence of that feature.
> 
> gdb-mi is buggy and the usability is poor.

When did you last try it?  If the recent versions still fit the
description of "buggy" and "poor usability", we'd appreciate bug
reports about specific shortcomings, TIA.

> Anecdotally, the most common Emacs FAQ I encounter is about gdb and
> the user is always satisfied once pointed to gud-gdb.

When was the last time you encountered that?

> The "gdb" command ought to invoke what "gud-gdb" does today.

Do you mean UI-wise, or do you mean it should use annotations instead
of the MI interface?

This discussion is about the UI.  The basic UI presented by "M-x gdb"
is almost identical to "gud-gdb", with the exception of popping the
I/O window if and when the debuggee outputs something, and a few minor
niceties like showing breakpoints on the fringes of the window that
displays the source.  Other than that, you get the same comint buffer
for CLI interaction and the same source display with an overlay arrow.
So I'm not sure what usability problems could plague gdb-mi that don't
affect gud-gdb.  Specific bug reports are welcome.

The interface used to communicate with GDB is a separate matter,
unrelated to this discussion.  Again, if you have specific bugs to
report about that, please do.

Re: Use of dedicated windows in gdb-mi.el

[Glenn Brown]

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

I applaud the efforts to make gdb-mode more friendly to novices.

However, as as 20+ year users of 'M-x gdb' in emacs, I, too, find recent
changes to the default 'M-x gdb' behavior frustrating and
counter-productive for my own work: I miss inline output in the *gud*
frame: I am daily annoyed at output opening a new window I didn't ask for,
which I must manually close or 'Ctrl-x o' (other-window) past, since I am
often in 'emacs -nw' (No mouse) on remote machines.  I am annoyed that the
new window-that-I-never-asked-for won't let me 'Ctrl-x b'
(switch-to-buffer) to the buffer I actually want to see.

I understand that novices tend to use print-debugging and the new
input/output buffer can be useful to them.  I appreciate that the default
configuration should be optimized for novices doing native development in a
windowed environment.
But please understand that many professionals develop code where
stdout-in-its-own-window is counter-productive.  (In my daily use, the only
output is from the testing framework I use.)  Please understand that not
everyone has access to a mouse when doing remote and/or embedded
development.

So please, gdb-mode maintainers, if you are going to change the default
behaviour of gdb-mode, give us an easy way to get back access the old
output-in-the-*gud*-buffer behavior, which is more productive for some of
us professionals.

Thanks for your consideration,
--Glenn

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

Re: Use of dedicated windows in gdb-mi.el

[Oleh Krehel]

Hi Glenn,

Glenn Brown <glennb@google.com> writes:

> I applaud the efforts to make gdb-mode more friendly to novices.
>
> However, as as 20+ year users of 'M-x gdb' in emacs, I, too, find
> recent changes to the default 'M-x gdb' behavior frustrating and
> counter-productive for my own work: I miss inline output in the *gud*
> frame: I am daily annoyed at output opening a new window I didn't ask
> for, which I must manually close or 'Ctrl-x o' (other-window) past,
> since I am often in 'emacs -nw' (No mouse) on remote machines. I am
> annoyed that the new window-that-I-never-asked-for won't let me
> 'Ctrl-x b' (switch-to-buffer) to the buffer I actually want to see.
>
> I understand that novices tend to use print-debugging and the new
> input/output buffer can be useful to them. I appreciate that the
> default configuration should be optimized for novices doing native
> development in a windowed environment.
> But please understand that many professionals develop code where
> stdout-in-its-own-window is counter-productive. (In my daily use, the
> only output is from the testing framework I use.) Please understand
> that not everyone has access to a mouse when doing remote and/or
> embedded development.
>
> So please, gdb-mode maintainers, if you are going to change the
> default behaviour of gdb-mode, give us an easy way to get back access
> the old output-in-the-*gud*-buffer behavior, which is more productive
> for some of us professionals.
>
> Thanks for your consideration,
> --Glenn

I don't understand, I was the last one to touch gdb-mi.el in a year and
I didn't change any default behavior, only introduced a new defcustom
that changes the behavior if someone sets it. Are you referring to my
change?

Oleh

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> From: Glenn Brown <glennb@google.com>
> Date: Tue, 24 Feb 2015 09:56:07 -0800
> Cc: ohwoeowho@gmail.com
> 
> So please, gdb-mode maintainers, if you are going to change the default
> behaviour of gdb-mode, give us an easy way to get back access the old
> output-in-the-*gud*-buffer behavior, which is more productive for some of us
> professionals.

The old GDB UI in Emacs is still available via "M-x gud-gdb".

Re: Use of dedicated windows in gdb-mi.el

[Paul Eggert]

On 02/24/2015 10:31 AM, Eli Zaretskii wrote:
> The old GDB UI in Emacs is still available via "M-x gud-gdb".

Yes, that's what I use.  I tried the newish "M-x gdb" a few times and 
was annoyed by the same things that annoy Glenn Brown. Dedicated windows 
that cannot switch buffers can be quite frustrating for people who want 
to use Emacs to edit as well as to debug.

This isn't due to Oleh's recent changes; it's due to the big change to 
M-x gdb in Emacs 23.

Re: Use of dedicated windows in gdb-mi.el

[Eli Zaretskii]

> Date: Tue, 24 Feb 2015 14:23:29 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On 02/24/2015 10:31 AM, Eli Zaretskii wrote:
> > The old GDB UI in Emacs is still available via "M-x gud-gdb".
> 
> Yes, that's what I use.  I tried the newish "M-x gdb" a few times and 
> was annoyed by the same things that annoy Glenn Brown. Dedicated windows 
> that cannot switch buffers can be quite frustrating for people who want 
> to use Emacs to edit as well as to debug.

It's a matter of habit.  I, on the contrary, had no problems getting
used to the new behavior, FWIW.

Re: Use of dedicated windows in gdb-mi.el

[Stefan Monnier]

> Yes, that's what I use.  I tried the newish "M-x gdb" a few times and was
> annoyed by the same things that annoy Glenn Brown.

I wasn't annoyed by dedicated windows, but I also use M-x gud-gdb, FWIW
(I was annoyed by the unreliability of M-x gdb, tho I haven't tried it
again for a long time now).


        Stefan

Re: Use of dedicated windows in gdb-mi.el

[Glenn Brown]

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

M-x gud-gdb is *exactly* what I was looking for.  Thanks, Stefan!  (And
thanks to the maintainers who preserved this functionality.)

Thanks again,
--Glenn

On Tue, Feb 24, 2015 at 7:57 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > Yes, that's what I use.  I tried the newish "M-x gdb" a few times and was
> > annoyed by the same things that annoy Glenn Brown.
>
> I wasn't annoyed by dedicated windows, but I also use M-x gud-gdb, FWIW
> (I was annoyed by the unreliability of M-x gdb, tho I haven't tried it
> again for a long time now).
>
>
>         Stefan
>

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