Re: [ jEdit-users ] Plugins under development

[Shlomy R. <shl...@01...>]

Thanks for pointing this out. I actually thought that the emacs
integration with gdb is much more in the GUI direction. Eclipse CDT
Debugger does not show the gdb command-line (at least I never saw such
an option), as the entire integration is graphical, like in MSDEV. You
don't type any commands and see textual output - you give commands to
the debugger using mouse clicks and GUI dialogs, and you get information
from the debugger in GUI widgets.

I intend to use the gdb/mi interface rather than the CLI. I don't know
if gdb/mi enables usage of the CLI as well, but if not, there is no
point (almost) in providing a "gdb console" since the gdb/mi is not
meant to be human-readable, it was designed to be easier to use by
programs (mi=machine interface). I will not design the gdb plugin to use
the CLI instead of mi just in order to provide a "gdb console". In
general, if you want to use the gdb command-line rather than GUI, and
the only added value in the integration is that the output is stored in
a buffer and that it can jump to source locations when navigating stack
frames, then I think you can simply run gdb in the Console plugin, which
can be slightly enhanced to jump into source locations that appear in
the output. Am I wrong? If I'm correct, I can help with adding this
feature to the Console plugin.

I will, of course, provide an option to specify the path to gdb. But it
should be a gdb that supports gdb/mi. In the emacs gdb integration that
you describe below, I don't see a lot of difference between running
'gdb' and running any other interactive tool...

Shlomy

On Thu, 2007-01-25 at 21:18 -0800, Marcelo Vanzin wrote:
> Hi Shlomy,
> 
> Shlomy Reinstein wrote:
> > with jEdit. The kind of integration I have in mind is like the Eclipse
> > CDT Debugger with some minor changes. I'm not familiar with the emacs
> > gdb integration but I guess the CDT Debugger is at least as good,
> > correct me if I'm wrong.
> 
> I've never used the Eclipse debugger, but the emacs/gdb interface is not
> much more than a glorified command line embedded in a emacs buffer. If
> you have emacs installed, hit ALT-x and type "gdb" and try it out.
> 
> The nice things about it:
> 
> - it gives you a chance to choose the gdb you're using. In my last job
> we had a special gdb that worked with the binaries for their CPU
> architecture; so when debugging those binaries we'd use one gdb, when
> debugging Linux binaries we'd use the Linux gdb.
> 
> - it gives you access to all the gdb command line, which is very
> powerful, and a lot of people prefer over fancy GUIs that don't provide
> all those functions/
> 
> - while navigating stack frames, it tries to navigate through the source
> code with you, automatically. It splits the view and keeps the other
> pane in sync with what you're looking at. the command line gdb has an
> option for that, but it's kinda cumbersome to use from my experience.
> 
> - it keeps all gdb output in the buffer, so you can use all emacs
> functions to edit/search/etc in the session.
> 
> I'm not against adding nice variable watch views, enabling/disabling
> breakpoints directly in the source file, etc, but the real nice thing,
> for gdb at least, would be not to hide gdb's command interface.
> 
> The same can't really be said about jdb, for example, since it kinda
> sucks. :-) But a front-end like that could be used to run things like
> pdb (the built-in python debugger) without many changes (since the idea
> would be the same - just a wrapper around a command line utility, using
> a jEdit buffer as the "terminal").
> 
> -- 
> Marcelo Vanzin
> va...@us...
> "Life is too short to drink cheap beer"
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV