[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: Use of dedicated windows in gdb-mi.el
Date: Tue, 10 Feb 2015 18:05:52 +0200

> Date: Mon, 9 Feb 2015 16:49:43 -0800
> From: Barry OReilly <address@hidden>
> > 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]