* Difficulty using M-x gdb
@ 2023-02-01 14:53 Michael Welsh Duggan
2023-02-01 17:07 ` Eli Zaretskii
2023-02-03 21:35 ` Konstantin Kharlamov
0 siblings, 2 replies; 10+ messages in thread
From: Michael Welsh Duggan @ 2023-02-01 14:53 UTC (permalink / raw)
To: emacs-devel
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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-01 14:53 Difficulty using M-x gdb Michael Welsh Duggan
@ 2023-02-01 17:07 ` Eli Zaretskii
2023-02-01 23:18 ` Yuan Fu
2023-02-02 18:50 ` Eli Zaretskii
2023-02-03 21:35 ` Konstantin Kharlamov
1 sibling, 2 replies; 10+ messages in thread
From: Eli Zaretskii @ 2023-02-01 17:07 UTC (permalink / raw)
To: Michael Welsh Duggan; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-01 17:07 ` Eli Zaretskii
@ 2023-02-01 23:18 ` Yuan Fu
2023-02-01 23:53 ` Dmitry Gutov
2023-02-02 18:50 ` Eli Zaretskii
1 sibling, 1 reply; 10+ messages in thread
From: Yuan Fu @ 2023-02-01 23:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Michael Welsh Duggan, emacs-devel
>
>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-01 23:18 ` Yuan Fu
@ 2023-02-01 23:53 ` Dmitry Gutov
2023-02-02 0:18 ` Dmitry Gutov
0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Gutov @ 2023-02-01 23:53 UTC (permalink / raw)
To: Yuan Fu, Eli Zaretskii; +Cc: Michael Welsh Duggan, emacs-devel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-01 23:53 ` Dmitry Gutov
@ 2023-02-02 0:18 ` Dmitry Gutov
0 siblings, 0 replies; 10+ messages in thread
From: Dmitry Gutov @ 2023-02-02 0:18 UTC (permalink / raw)
To: Yuan Fu, Eli Zaretskii; +Cc: Michael Welsh Duggan, emacs-devel
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. ;-(
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-01 17:07 ` Eli Zaretskii
2023-02-01 23:18 ` Yuan Fu
@ 2023-02-02 18:50 ` Eli Zaretskii
2023-02-05 15:26 ` Madhu
1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2023-02-02 18:50 UTC (permalink / raw)
To: mwd; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-01 14:53 Difficulty using M-x gdb Michael Welsh Duggan
2023-02-01 17:07 ` Eli Zaretskii
@ 2023-02-03 21:35 ` Konstantin Kharlamov
1 sibling, 0 replies; 10+ messages in thread
From: Konstantin Kharlamov @ 2023-02-03 21:35 UTC (permalink / raw)
To: Michael Welsh Duggan, emacs-devel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-02 18:50 ` Eli Zaretskii
@ 2023-02-05 15:26 ` Madhu
2023-02-05 15:33 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Madhu @ 2023-02-05 15:26 UTC (permalink / raw)
To: emacs-devel
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]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-05 15:26 ` Madhu
@ 2023-02-05 15:33 ` Eli Zaretskii
2023-02-06 23:23 ` Madhu
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2023-02-05 15:33 UTC (permalink / raw)
To: Madhu; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Difficulty using M-x gdb
2023-02-05 15:33 ` Eli Zaretskii
@ 2023-02-06 23:23 ` Madhu
0 siblings, 0 replies; 10+ messages in thread
From: Madhu @ 2023-02-06 23:23 UTC (permalink / raw)
To: eliz; +Cc: emacs-devel
* 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! :)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-02-06 23:23 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-02-01 14:53 Difficulty using M-x gdb Michael Welsh Duggan
2023-02-01 17:07 ` Eli Zaretskii
2023-02-01 23:18 ` Yuan Fu
2023-02-01 23:53 ` Dmitry Gutov
2023-02-02 0:18 ` Dmitry Gutov
2023-02-02 18:50 ` Eli Zaretskii
2023-02-05 15:26 ` Madhu
2023-02-05 15:33 ` Eli Zaretskii
2023-02-06 23:23 ` Madhu
2023-02-03 21:35 ` Konstantin Kharlamov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).