Difficulty using M-x gdb

Difficulty using M-x gdb

[Michael Welsh Duggan]

I have used "M-x gud-gdb" to run gdb for many years.  I used it for
quite a while after the gdb-mi interface was added due to its ability to
debug the same program multiple times at the same time in the same
Emacs.  I don't need that capability right now. 

Due to a bug in `gud-gdb` (#61162) I am trying to switch to "M-x gdb"
instead.  Unfortunately, I can't really figure out how to make this work
in a way that makes sense to me.  `gdb-many-windows` being nil is the
default, and the default should be reasonably easy to use (one would
hope), but I am having the following problem:

When I step through a program, the interface keeps track of where I am
in the source buffer.  But, when the program produces output, it
replaces the source buffer window with an input/output buffer window
which is dedicated.  The only way I have found out to display the source
buffer again is to use "M-x gdb-restore-windows".  In code that is doing
a fair amount of output, this is very tedious.

What is right way to handle this?  If it requires customization, why is
customization needed to make this fairly common case work well?  Is
there a way to make output go the interaction buffer?  Maybe most
importantly, this input/output buffer/window doesn't seem to be
mentioned in the Emacs documentation at all.

I have my suspicions that, once I get used to the new interface, I might
like using it, but right now I'm having difficulty figuring out what
habits I need to relearn.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Difficulty using M-x gdb

[Eli Zaretskii]

> From: Michael Welsh Duggan <mwd@md5i.com>
> Date: Wed, 01 Feb 2023 09:53:05 -0500
> 
> When I step through a program, the interface keeps track of where I am
> in the source buffer.  But, when the program produces output, it
> replaces the source buffer window with an input/output buffer window
> which is dedicated.  The only way I have found out to display the source
> buffer again is to use "M-x gdb-restore-windows".  In code that is doing
> a fair amount of output, this is very tedious.
> 
> What is right way to handle this?

Try "M-x gdb-display-io-buffer RET".  (You can also activate that
window (or any other gdb-mi window) via the menu bar's
Gud->GDB-Windows menu.)

> If it requires customization, why is
> customization needed to make this fairly common case work well?

Not every program communicates via stdin/stdout, and when a program
doesn't, popping up another window would be a nuisance, I think.

> Maybe most importantly, this input/output buffer/window doesn't seem
> to be mentioned in the Emacs documentation at all.

It is mentioned, but maybe not prominently enough.  Patches welcome,
or I will get to adding that soon.

> I have my suspicions that, once I get used to the new interface, I might
> like using it, but right now I'm having difficulty figuring out what
> habits I need to relearn.

My suggestion is to start with gdb-many-windows, and then close those
windows you don't need.

Re: Difficulty using M-x gdb

[Yuan Fu]

> 
>> I have my suspicions that, once I get used to the new interface, I might
>> like using it, but right now I'm having difficulty figuring out what
>> habits I need to relearn.
> 
> My suggestion is to start with gdb-many-windows, and then close those
> windows you don't need.

And you can use gdb-save-window-configuration to save the window configuration once you are satisfied with it. I wonder which nice fellow added that function ;-)

Yuan

Re: Difficulty using M-x gdb

[Dmitry Gutov]

On 02/02/2023 01:18, Yuan Fu wrote:
>>> I have my suspicions that, once I get used to the new interface, I might
>>> like using it, but right now I'm having difficulty figuring out what
>>> habits I need to relearn.
>> My suggestion is to start with gdb-many-windows, and then close those
>> windows you don't need.
> And you can use gdb-save-window-configuration to save the window configuration once you are satisfied with it. I wonder which nice fellow added that function 😉

Oh well. I guess I missed that.

Re: Difficulty using M-x gdb

[Dmitry Gutov]

On 02/02/2023 01:53, Dmitry Gutov wrote:
> On 02/02/2023 01:18, Yuan Fu wrote:
>>>> I have my suspicions that, once I get used to the new interface, I 
>>>> might
>>>> like using it, but right now I'm having difficulty figuring out what
>>>> habits I need to relearn.
>>> My suggestion is to start with gdb-many-windows, and then close those
>>> windows you don't need.
>> And you can use gdb-save-window-configuration to save the window 
>> configuration once you are satisfied with it. I wonder which nice 
>> fellow added that function 😉
> 
> Oh well. I guess I missed that.

Sorry, wrong thread. ;-(

Re: Difficulty using M-x gdb

[Eli Zaretskii]

> Date: Wed, 01 Feb 2023 19:07:18 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Maybe most importantly, this input/output buffer/window doesn't seem
> > to be mentioned in the Emacs documentation at all.
> 
> It is mentioned, but maybe not prominently enough.  Patches welcome,
> or I will get to adding that soon.

Done.

Re: Difficulty using M-x gdb

[Madhu]

Wanted to mention One problem I noticed with M-x gdb is that source code
buffers end up with permanent local binding of 'gdbmi for the variable
gud-minor-mode, and this intercepts keys RET and tries to send them to
the gud comint buffer even when gdb is not in action.  Haven't figured
out where this happens but I've had to overcome this by setting ``` M-:
(setq gub-minor-mode nil) ``` in affected buffers.

[I share much the same experience with the original poster, and all my
lost debugging skills on encountering gdb-mi like in a stroke, but I'm
still making an effort to come to terms with gdb-mi, but its still
uphill with 80 col screens and being limited to C-x o to switch between
windows]

Re: Difficulty using M-x gdb

[Eli Zaretskii]

> From: Madhu <enometh@meer.net>
> Date: Sun, 05 Feb 2023 20:56:23 +0530
> 
> 
> Wanted to mention One problem I noticed with M-x gdb is that source code
> buffers end up with permanent local binding of 'gdbmi for the variable
> gud-minor-mode, and this intercepts keys RET and tries to send them to
> the gud comint buffer even when gdb is not in action.  Haven't figured
> out where this happens but I've had to overcome this by setting ``` M-:
> (setq gub-minor-mode nil) ``` in affected buffers.

On which branch?  I don't see this on emacs-29, only on master (where
the changes which cause all this have not been reverted yet, in the
hope that someone will find a better way of fixing the breakage).

> [I share much the same experience with the original poster, and all my
> lost debugging skills on encountering gdb-mi like in a stroke, but I'm
> still making an effort to come to terms with gdb-mi, but its still
> uphill with 80 col screens and being limited to C-x o to switch between
> windows]

Sorry, I don't think I understand what this rant is about.

Re: Difficulty using M-x gdb

[Madhu]

*  Eli Zaretskii <eliz@gnu.org> <83sffkqg7y.fsf @gnu.org>
Wrote on Sun, 05 Feb 2023 17:33:53 +0200
>> From: Madhu <enometh@meer.net>
>> Date: Sun, 05 Feb 2023 20:56:23 +0530
>>
>> Wanted to mention One problem I noticed with M-x gdb is that source code
>> buffers end up with permanent local binding of 'gdbmi for the variable
>> gud-minor-mode, and this intercepts keys RET and tries to send them to
>> the gud comint buffer even when gdb is not in action.  Haven't figured
>> out where this happens but I've had to overcome this by setting ``` M-:
>> (setq gub-minor-mode nil) ``` in affected buffers.
>
> On which branch?  I don't see this on emacs-29, only on master (where
> the changes which cause all this have not been reverted yet, in the
> hope that someone will find a better way of fixing the breakage).

Yes, it was only on the master branch.  (I didn't dig into the
details, but I will the next time I use the debugger)

[...]

> Sorry, I don't think I understand what this rant is about.

nevermind! :)

Re: Difficulty using M-x gdb

[Konstantin Kharlamov]

On Wed, 2023-02-01 at 09:53 -0500, Michael Welsh Duggan wrote:
> I have used "M-x gud-gdb" to run gdb for many years.  I used it for
> quite a while after the gdb-mi interface was added due to its ability to
> debug the same program multiple times at the same time in the same
> Emacs.  I don't need that capability right now. 
> 
> Due to a bug in `gud-gdb` (#61162) I am trying to switch to "M-x gdb"
> instead.  Unfortunately, I can't really figure out how to make this work
> in a way that makes sense to me.  `gdb-many-windows` being nil is the
> default, and the default should be reasonably easy to use (one would
> hope), but I am having the following problem:
> 
> When I step through a program, the interface keeps track of where I am
> in the source buffer.  But, when the program produces output, it
> replaces the source buffer window with an input/output buffer window
> which is dedicated.  The only way I have found out to display the source
> buffer again is to use "M-x gdb-restore-windows".  In code that is doing
> a fair amount of output, this is very tedious.
> 
> What is right way to handle this?  If it requires customization, why is
> customization needed to make this fairly common case work well?  Is
> there a way to make output go the interaction buffer?  Maybe most
> importantly, this input/output buffer/window doesn't seem to be
> mentioned in the Emacs documentation at all.
> 
> I have my suspicions that, once I get used to the new interface, I might
> like using it, but right now I'm having difficulty figuring out what
> habits I need to relearn.

FWIW, I have the following code in my config that fixes the behavior you
mention.

    ;; Force gdb-mi to not dedicate any windows
    (advice-add 'gdb-display-buffer
            :around (lambda (orig-fun &rest r)
                  (let ((window (apply orig-fun r)))
                (set-window-dedicated-p window nil)
                window)))

With that said, neither I think it's a useful default behavior to replace a
window with a source code file with the one that shows app output.