Using gdb (windows popping up)

Using gdb (windows popping up)

[jonetsu]

Hello,

I'm trying to simply get a debug session going on in a minimal way that
is, gdb in one buffer (window) and the source in the other buffer
(window), both being displayed side by side.  Simple enough, and the
customize-variable gdb-show-main set to non-nil allows just for this to
happen.

The gdb session starts (M-x gdb) with on the left gdb and on the right
the source.  In the source a breakpoint can be placed in the margin.
All fine, looks very good...

... until the debugging session starts.  At which point emacs decides
to create a new whole emacs app/window with the source code in it.  It
boldly replaces the source window with the debugged app's output window
and throws the source into a new emacs instance.

But the source code was already displayed and a breakpoint was set in
it showing that it is active and linked to gdb.  Why do that ?  If you
really want to show the output window, why not split the gdb window ?
Or maybe totally forget about the output window until the user wants
it ?  

Or is there a variable or two to control this ?  I read through the
documentation and did not find anything so far.  I would just like to
establish a clean working state with emacs and gdb in which things are
not popping up unexpectedly in new instances of emacs.  Emacs version
is 26.1.  Speedbar is not used in this case.

Cheers.

Re: Using gdb (windows popping up)

[jonetsu]

On Sun, 9 Jun 2019 11:52:46 -0400
jonetsu <jonetsu@teksavvy.com> wrote:

> ... until the debugging session starts.  At which point emacs decides
> to create a new whole emacs app/window with the source code in it.  It
> boldly replaces the source window with the debugged app's output
> window and throws the source into a new emacs instance.

Using sr-speedbar-open prior to starting gdb solves the problem of
popping up a new emacs instance.  That is, sr-speedbar with the
following added in .emacs (which I found in stack exchange, regarding
speedbar not being able to use the current emacs frame)

(defadvice delete-other-windows (after
my-sr-speedbar-delete-other-window-advice activate) "Check whether we
are in speedbar, if it is, jump to next window." (let ()
	(when (and (sr-speedbar-window-exist-p sr-speedbar-window)
               (eq sr-speedbar-window (selected-window)))
      (other-window 1)
	)))
(ad-enable-advice 'delete-other-windows 'after
'my-sr-speedbar-delete-other-window-advice) (ad-activate
'delete-other-windows)

Since emacs/gdb will use speedbar anyways to display watch items, might
as well load it up front.

So this seems to resolve the problem with new instances popping up.

Re: Using gdb (windows popping up)

[jonetsu]

On Sun, 9 Jun 2019 12:09:08 -0400
jonetsu <jonetsu@teksavvy.com> wrote:

> So this seems to resolve the problem with new instances popping up.

... Until the debugged app outputs something.  Then yes, the problem
with a new emacs instance popping is solved, but emacs insists on
replacing the source code with the output window.  At which point,
putting the cursor in that output window and selecting the source
buffer to be displayed right there where the cursor is (as this is the
normal behaviour in emacs) will show the source in the gdb
interactive window, tossing it away.

Putting away the output window (C-x 0) and selecting the source code
buffer, as well as bringing up the gdb interactive window gets back on
track ... until the next output is made by the debugged app.  At which
point another 'dance of the windows' has to be made.

The output window was not closed, only toss away (C-x 0) - why not
output anything fro the debugged app in there without having to show it
and replace the source buffer ?

It's a bit of a mess.  I'd like to establish a good clean simple base
to work with emacs and gdb - is it possible at all ?

Reading here and there about similar problem pops up a lot of
suggestions, a lot of them.  Install this, install that, do this .emacs
modification, add this - oh not that doe snot work - then add that
instead, etc, etc...

Re: Using gdb (windows popping up)

[jonetsu]

On Sun, 9 Jun 2019 12:18:23 -0400
jonetsu <jonetsu@teksavvy.com> wrote:

> ... Until the debugged app outputs something.  Then yes, the problem
> with a new emacs instance popping is solved, but emacs insists on
> replacing the source code with the output window.  

Found out that this is solved by setting the following variable to
non-nil (default is nil) :

gdb-display-io-nopopup

Also saw that there are incredible people with lots of patience, as
this Stack Exchange post on this topic shows, with the subject:

"How can I prevent gdb *input/output* buffer from aggressively popping
up in frame?"

The above solution is presented and the reply was:

"Thank you, thank you, thank you! This has been an irritation for me for
years!"

I mean, years ?  I couldn't stand it for a day ! :)

Re: Using gdb (windows popping up)

[Óscar Fuentes]

jonetsu <jonetsu@teksavvy.com> writes:

> On Sun, 9 Jun 2019 12:18:23 -0400
> jonetsu <jonetsu@teksavvy.com> wrote:
>
>> ... Until the debugged app outputs something.  Then yes, the problem
>> with a new emacs instance popping is solved, but emacs insists on
>> replacing the source code with the output window.  
>
> Found out that this is solved by setting the following variable to
> non-nil (default is nil) :
>
> gdb-display-io-nopopup
>
> Also saw that there are incredible people with lots of patience, as
> this Stack Exchange post on this topic shows, with the subject:
>
> "How can I prevent gdb *input/output* buffer from aggressively popping
> up in frame?"
>
> The above solution is presented and the reply was:
>
> "Thank you, thank you, thank you! This has been an irritation for me for
> years!"
>
> I mean, years ?  I couldn't stand it for a day ! :)

Due to this issues with windows and frames popping out, I don't use
Emacs' gdb interface, but will give it another chance with this trick
next time, thanks.

Please use M-x report-emacs-bug to report about this issues to the Emacs
maintainers and mention your workaround.

Re: Using gdb (windows popping up)

[Eli Zaretskii]

> Date: Sun, 9 Jun 2019 11:52:46 -0400
> From: jonetsu <jonetsu@teksavvy.com>
> 
> The gdb session starts (M-x gdb) with on the left gdb and on the right
> the source.  In the source a breakpoint can be placed in the margin.
> All fine, looks very good...
> 
> ... until the debugging session starts.  At which point emacs decides
> to create a new whole emacs app/window with the source code in it.  It
> boldly replaces the source window with the debugged app's output window
> and throws the source into a new emacs instance.
> 
> But the source code was already displayed and a breakpoint was set in
> it showing that it is active and linked to gdb.  Why do that ?  If you
> really want to show the output window, why not split the gdb window ?
> Or maybe totally forget about the output window until the user wants
> it ?  

"M-x gdb" works with dedicated windows, my suggestion is not to fight
it wrt windows.  If you want to display your own windows, do so in
another frame.

Alternatively, after "M-x gdb" type "start ARGUMENTS" to start the
program and stop it at the entry to the main function.  Then set your
breakpoints after switching to the source file you want in the window
where Emacs shows the file with the main function.

As yet another alternative, customize gdb-show-main to a non-nil
value, and then "M-x gdb" will automatically show the source file with
the main function in a window; switch in that window to your other
source file where you want to set a breakpoint, then start the
program.

HTH

Re: Using gdb (windows popping up)

[jonetsu]

On Sun, 09 Jun 2019 21:31:47 +0300
Eli Zaretskii <eliz@gnu.org> wrote:

> Alternatively, after "M-x gdb" type "start ARGUMENTS" to start the
> program and stop it at the entry to the main function.  Then set your
> breakpoints after switching to the source file you want in the window
> where Emacs shows the file with the main function.

At the moment I seem to have attained a stable procedure.  In the sense
that the overhead is now limited and predictable.
 
> As yet another alternative, customize gdb-show-main to a non-nil
> value, and then "M-x gdb" will automatically show the source file with
> the main function in a window; switch in that window to your other
> source file where you want to set a breakpoint, then start the
> program.

Yes, gdb-show-main is set to non-nil.  And yes, it will then show the
source beside the gdb interactive buffer.... until a printf/cout
statement is issued at which point the input/output window will
"aggressively" - as it was termed in a Stack Exchange topic - take over
and decide where any other buffer you deem to see will be actually
located.  Fortunately, the fix I found, setting gdb-display-io-nopopup
(starting at emacs 25) to non-nil solves the issue and brings back
peace of mind regarding the expected freedom one expects in emacs
regarding placing buffers where one wants them.  In other words, if
removes a good part of the tool's quirks in this context and enables
one to concentrate on work.

That such behaviour found its way in emacs is something else.  Imagine
any power tool built wit such quirkiness. 

Re: Using gdb (windows popping up)

[Eli Zaretskii]

> Date: Sun, 9 Jun 2019 14:59:21 -0400
> From: jonetsu <jonetsu@teksavvy.com>
> 
> > As yet another alternative, customize gdb-show-main to a non-nil
> > value, and then "M-x gdb" will automatically show the source file with
> > the main function in a window; switch in that window to your other
> > source file where you want to set a breakpoint, then start the
> > program.
> 
> Yes, gdb-show-main is set to non-nil.  And yes, it will then show the
> source beside the gdb interactive buffer.... until a printf/cout
> statement is issued at which point the input/output window will
> "aggressively" - as it was termed in a Stack Exchange topic - take over
> and decide where any other buffer you deem to see will be actually
> located.

That's a different issue.  Your original complaint was about popping
up source buffers, and that's what I was trying to help you with.

> Fortunately, the fix I found, setting gdb-display-io-nopopup
> (starting at emacs 25) to non-nil solves the issue and brings back
> peace of mind regarding the expected freedom one expects in emacs
> regarding placing buffers where one wants them.  In other words, if
> removes a good part of the tool's quirks in this context and enables
> one to concentrate on work.

So the problem is solved.  I'm glad.

My personal advice is to start the debugging session with "M-x
gdb-many-windows", which will open all the UI windows, including I/O.
I believe in this case the program's output will be inserted into the
I/O window, and will not usurp any of your other windows.

> That such behaviour found its way in emacs is something else.  Imagine
> any power tool built wit such quirkiness. 

Once again, the GDB-MI UI was designed to work with dedicated windows,
to mimic GUI front ends to debuggers.  The user manual even advises to
start "M-x gdb" in a separate frame, so as not to interfere with any
window arrangement you may be using when not debugging.

Re: Using gdb (windows popping up)

[jonetsu]

On Sun, 09 Jun 2019 22:13:08 +0300
Eli Zaretskii <eliz@gnu.org> wrote:

> My personal advice is to start the debugging session with "M-x
> gdb-many-windows", which will open all the UI windows, including I/O.
> I believe in this case the program's output will be inserted into the
> I/O window, and will not usurp any of your other windows.

In the previous approach I took, yesterday, I set gdb-many-windows to
non-nil and immediately experienced that control over where one wants
the buffers to be displayed becomes tense, so to speak.  A bit like
fighting with a word processor that insists that paragraphs must be
formatted in one way.

So I now prefer to drop that many windows approach and open up other
gdb windows as need arises.  This let me place buffers in a more
reasonable way.  Only setting the gdb-show-main variable to non-nil so
that a M-x gdb session starts with two buffers, source and gdb
interactive.  Then I can split windows in every which way to show any
other buffer, add a gdb input/output window before it decides on its own
to show one, etc..  This is with sr-speedbar and the lisp snippet I've
shown in this thread.

Yes, I've seen that the manual advises to uses M-x gdb in a distinct
frame.  The problem with this is that while debugging I can consult
other non-gdb buffers, sometimes for a while, before doing the next
debugger step.  Doing this on Linux switching to a different desktop is
easy, although I still prefer to have one emacs session where all the
files are, and not two of them.  The approach I'm using now seems to
support that.

Re: Using gdb (windows popping up)

[Noam Postavsky]

On Sun, 9 Jun 2019 at 15:27, jonetsu <jonetsu@teksavvy.com> wrote:

> Yes, I've seen that the manual advises to uses M-x gdb in a distinct
> frame.  The problem with this is that while debugging I can consult
> other non-gdb buffers, sometimes for a while, before doing the next
> debugger step.  Doing this on Linux switching to a different desktop is
> easy, although I still prefer to have one emacs session where all the
> files are, and not two of them.

(I have no opinion on the gdb-many-windows settings, but) you seem to
be conflating frames with "sessions" or "instances". A single Emacs
instance/session can have multiple frames, i.e., it's the same set of
buffers, variables, etc.

Re: Using gdb (windows popping up)

[jonetsu]

On Sun, 9 Jun 2019 15:33:03 -0400
Noam Postavsky <npostavs@gmail.com> wrote:

> (I have no opinion on the gdb-many-windows settings, but) you seem to
> be conflating frames with "sessions" or "instances". A single Emacs
> instance/session can have multiple frames, i.e., it's the same set of
> buffers, variables, etc.

Yes, I'm terrible with those terms and definitions.  I meant a distinct
emacs instance in this case.

It also means that I'm not quite sure about frames.  Windows seems to
be what can be divided by using C-x 2, c-x 3.  In each window is a
buffer.  When having several buffers shown in various windows, that can
be saved using C-x r w [key] and recalled using C-x j [key].  Several
windows/buffers placements can be saved and recalled that way.

And so, what are frames actually ?

Re: Using gdb (windows popping up)

[Noam Postavsky]

On Sun, 9 Jun 2019 at 15:49, jonetsu <jonetsu@teksavvy.com> wrote:

> And so, what are frames actually ?

The thing containing the windows. See also (info "(emacs) Frames").

https://www.gnu.org/software/emacs/manual/html_node/emacs/Frames.html

Re: Using gdb (windows popping up)

[jonetsu]

On Sun, 9 Jun 2019 16:15:17 -0400
Noam Postavsky <npostavs@gmail.com> wrote:

> The thing containing the windows. See also (info "(emacs) Frames").
> 
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Frames.html

I see.  Although, without have read everything, and I'm certain there
are a lot of possibilities. it resumes itself for all practical
purposes much like another emacs instance, apart from sharing the same
underlying buffers.

In this case here, that M-x gdb shows the source code (gdb-main-window
non-nil) in another frame when the code starts running, while keeping
gdb interactive in the original frame, is the same as another instance.
Lost is the capability of seeing side-by-side gdb interactive and
source.  Of course the new frame can be tailored to show both, but
what's the point in doing that every time gdb starts running code ?

This is why I prefer so far the fix that fixes this automatic frame
generation mentioned earlier.   It enables free placement of buffers,
just like in regular single-frame emacs operation, while running gdb.

Re: Using gdb (windows popping up)

[Óscar Fuentes]

jonetsu <jonetsu@teksavvy.com> writes:

> On Sun, 9 Jun 2019 16:15:17 -0400
> Noam Postavsky <npostavs@gmail.com> wrote:
>
>> The thing containing the windows. See also (info "(emacs) Frames").
>> 
>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Frames.html
>
> I see.  Although, without have read everything, and I'm certain there
> are a lot of possibilities. it resumes itself for all practical
> purposes much like another emacs instance, apart from sharing the same
> underlying buffers.

There is a huge difference. A new Emacs instance does not share state
with other instances.

A frame is just what in modern GUI terminology is known as a toplevel
window, or what most users call a window. An Emacs instance can have
multiple frames, just like the same Firefox or LibreOffice instance can
have multiple windows.

Re: Using gdb (windows popping up)

[jonetsu]

On Mon, 10 Jun 2019 00:36:08 +0200
Óscar Fuentes <ofv@wanadoo.es> wrote:

> There is a huge difference. A new Emacs instance does not share state
> with other instances.
> 
> A frame is just what in modern GUI terminology is known as a toplevel
> window, or what most users call a window. An Emacs instance can have
> multiple frames, just like the same Firefox or LibreOffice instance
> can have multiple windows.

Yes, but for all user/practical purposes it is another instance in the
sense that another 'app' is popping up showing the source code, hiding
the other emacs beneath it, while the gdb interactive buffer remains in
this 'other app' underneath.

The effect wished by the user is one of having the gdb interactive
buffer side-by-side with the source code as the debugging execution is
made. Which is fairly normal, if not totally useful.  New frame or
new instance, the user effect remains the same: the source code is no
longer beside the debugging session.

As a summary, setting gdb-display-io-nopopup to non-nil adds a lot of
stability to what was otherwise termed as an "aggressive" approach of
popping up a frame.  

It adds a lot of stability, which is a way of saying that there's still
a bit of jitter at the beginning of a M-x gdb session, when the gdb
input/output window is brought up.  At that moment there's still a bit
of a brawl as emacs insists to order windows contrary to what the user
normally expects from emacs, but that can be dealt with and from there
on a stability is assured for the debugging session and the user has a
good amount of freedom in placing windows and buffers as they are
deemed to be: the usual emacs way.

gdb-display-io-nopopup (since emacs 25) seems to be the best solution
to a problem that perhaps should not have been there from the start.

Re: Using gdb (windows popping up)

[Óscar Fuentes]

jonetsu <jonetsu@teksavvy.com> writes:

> On Mon, 10 Jun 2019 00:36:08 +0200
> Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> There is a huge difference. A new Emacs instance does not share state
>> with other instances.
>> 
>> A frame is just what in modern GUI terminology is known as a toplevel
>> window, or what most users call a window. An Emacs instance can have
>> multiple frames, just like the same Firefox or LibreOffice instance
>> can have multiple windows.
>
> Yes, but for all user/practical purposes it is another instance

Emphatically: no.

> in the
> sense that another 'app' is popping up showing the source code, hiding
> the other emacs beneath it, while the gdb interactive buffer remains in
> this 'other app' underneath.

Even if what you see is everything that counts for you, the definition
of "instance" that you use is not correct, because you can change what
you see on frame1 while operating from frame2.

Re: Using gdb (windows popping up)

[jonetsu]

On Mon, 10 Jun 2019 15:44:01 +0200
Óscar Fuentes <ofv@wanadoo.es> wrote:

> Even if what you see is everything that counts for you, the definition
> of "instance" that you use is not correct, because you can change what
> you see on frame1 while operating from frame2.

Of course, it can be re-ordered.  The thing is, though, is this overhead
worthwhile to do at the beginning of each debugging session ?  What are
the benefits towards the work being done ?

Especially in the light that the M-x gdb session actually starts with
the gdb interactive buffer and source /automatically/ placed
side-by-side by emacs.  ... Only to be disrupted with the source thrown
into another frame as soon as the debugging session starts.

Re: Using gdb (windows popping up)

[Eli Zaretskii]

> Date: Mon, 10 Jun 2019 10:00:45 -0400
> From: jonetsu <jonetsu@teksavvy.com>
> 
> On Mon, 10 Jun 2019 15:44:01 +0200
> Óscar Fuentes <ofv@wanadoo.es> wrote:
> 
> > Even if what you see is everything that counts for you, the definition
> > of "instance" that you use is not correct, because you can change what
> > you see on frame1 while operating from frame2.
> 
> Of course, it can be re-ordered.  The thing is, though, is this overhead
> worthwhile to do at the beginning of each debugging session ?  What are
> the benefits towards the work being done ?

One again, the GDB UI was _designed_ to work in dedicated windows,
something that few Emacs features do.  I suggest not to fight that,
but instead find a way of coexisting peacefully with that design.

One way of coexisting peacefully is to invoke "M-x gdb" in a new
frame.  That is, first type "C-x 5 2" to create a new frame, then
invoke "M-x gdb" in that new frame.  This way, your window arrangement
in the original frame will be left intact.  Switching to that original
frame is easy both with a mouse and via keyboard, so this is what the
Emacs manual recommends.

> Especially in the light that the M-x gdb session actually starts with
> the gdb interactive buffer and source /automatically/ placed
> side-by-side by emacs.  ... Only to be disrupted with the source thrown
> into another frame as soon as the debugging session starts.

You can save the customization of gdb-many-windows with a non-nil
value for your future sessions, in which case Emacs will start with
all the UI windows right after you invoke "M-x gdb", thus avoiding
this temporary "disruption" altogether.

Re: Using gdb (windows popping up)

[jonetsu]

On Mon, 10 Jun 2019 18:44:47 +0300
Eli Zaretskii <eliz@gnu.org> wrote:

> One again, the GDB UI was _designed_ to work in dedicated windows,
> something that few Emacs features do.  I suggest not to fight that,
> but instead find a way of coexisting peacefully with that design.

And indeed, the approach I described in the last replies results in a
comfortable setup, which just a little bit of jitter at the beginning.
 
> One way of coexisting peacefully is to invoke "M-x gdb" in a new
> frame.  That is, first type "C-x 5 2" to create a new frame, then
> invoke "M-x gdb" in that new frame.  This way, your window arrangement
> in the original frame will be left intact.  Switching to that original
> frame is easy both with a mouse and via keyboard, so this is what the
> Emacs manual recommends.

Yes, I'll keep that in mind if needed, although the current approach
with gdb-display-io-nopopup set to non-nil is not bad at all as far as
getting close to a normal emacs use.

> You can save the customization of gdb-many-windows with a non-nil
> value for your future sessions, in which case Emacs will start with
> all the UI windows right after you invoke "M-x gdb", thus avoiding
> this temporary "disruption" altogether.

This is what I tried right before starting this thread (described in
the previous thread by me) and abandoned the approach altogether since
it becomes way too difficult to show dedicated non-gdb buffers which I
need during debugging as I take notes, refer to notes, refer to other
sources, etc.  I could switch to another frame (equivalent of another
app for all practical user interface purposes since it requires
switching over - switching over to another full screen frame on the
same desktop or another desktop) although I still like to do everything
in one emacs session/frame/instance, as I'm used to work with emacs.

The bottom line to this is that some people have decided that gdb (many
windows option) should be presented in a very specific way when there's
no need to do so at all, none whatsoever.  The user is absolutely
capable of freely choosing which gdb buffers to be shown and where,
while have full co-existence with any other buffers.  There are no
logical reasons to impose a specific placement of gdb buffers.  It will
not make debugging work better.  The chosen imposed presentation (many
windows option) is not adding any performance improvement to
debugging.  gdb has a lot of functions and IMHO any development in gud
would be towards integrating more of those functions - while not
imposing anything on the users.