bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Claus Fischer]

On Tue, Jan 09, 2018 at 10:39:25PM -0500, Noam Postavsky wrote:
> On Tue, Jan 9, 2018 at 7:33 AM, Claus Fischer
> <claus.fischer@clausfischer.com> wrote:
> 
> > A few years ago, I filed a bug about debugging unter Emacs with
> > gud and gdb.
> 
> Using a different email perhaps? I can't seem to find that bug.

My apologies - that was way back in 2009, and I forgot about the
details. In fact, I filed it as a bug report on Debian,
Bug No. 520647.

It's hard to follow up on those things when you're in the middle
of debugging something big, because the focus is on getting the
code running.

> Bug#2556 and Bug#22374 seem related, though I'm not sure if they are
> the same so I won't merge.
> 
> > Please forward this information to the gud-mode maintainers,
> 
> There aren't any such people, as far as I know, apart from general
> Emacs maintainers.

Well thanks a lot for your answer, I looked at both bugs, and they
seem both to be related.

Bug 2556 gives me an idea about a misunderstanding that might be at
the heart of the case. Up to now I thought that gud would select
the debugging buffer by looking at the buffer text, which is *gud...*
and select the window according to that text.

However (I hadn't looked at the lisp code and I'm not good at Lisp),
bug 2556 gives me the impression that gud mode stores a window id of
a window that is created in Emacs. That is, for me, a wholly new
line of thinking. That might explain the behaviour:

  * I run the program in xterm and it gives an error message

  * I have the file where I'm looking for the error in my Emacs;
    since that's the one I'm just working on
    (I have a single frame of Emacs at that time)

  * I run M-x gud-gdb and give the program name

  * I re-run the program once under gud to see if the error is
    reproducible, which it usually is
    (I have a record-replay facility in my program so if valgrind
    doesn't complain before, the program is fully deterministic.)

  * I switch to the buffer with the source code in order to set the
    break point - at this point, I usually switch buffer in the
    original frame - gud buffer is no longer visible

  * I type C-x a b to set the breakpoint

  * I split the frame (or not) and run the program within gud/gdb

  * It stops at the breakpoint

That's the simple scenario. Given the information that gud-mode stores
the gud window by its Emacs window id (is that so? perhaps you can
confirm), it's entirely conceivable that sometimes there are other
factors in the equation that assign other buffers to that window.

For instance: I recompile (M-x recompile, which I have on a function
key), run program again in the terminal, get to the next programming
error, re-load the program into gdb (file ...), and restart the
debugger. Very likely the gud buffer is then in a different window.

If that is so, the solution for me would be simple: let gud not
remember the window, but let it search for the window with buffer
name *gud...* and switch to that one. I have only one such buffer.

Just speculating here about Emacs internals. Perhaps you can comment
on whether this might make sense.

From the two bug reports, it seems that problem is biting a few users
sporadically. Perhaps we can manage to find a different strategy.

Regards,

Claus

-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

signature.asc
Description: PGP signature