[Geany-Devel] Querying current file and cursor location
dimitar.zhekov at gmail.com
Fri Jan 18 19:34:04 UTC 2013
On Fri, 18 Jan 2013 09:31:18 +0100
Thomas Young <thomasyoung at free.fr> wrote:
> btw. What's the situation for the 'Scope' plugin?
> e.g. Is this working / in active development?
It works since the first upload, the ChangeLog is long only because
it's very detailed.
Currently there are 2 known bugs: switching to Locals may cause
segfault (may be OK with update_all_views = true), and
gtk_tree_model_get(string) leaks everywhere (though you'll need to
debug a lot to reach 1MB). I fixed them and am testing ATM.
> Sounds like this aims to address some of the issues I can see with GUI
> integrated debugging, in particular the possibility to still interact
> directly (and to some extent 'properly') with gdb.
You can send any gdb command at any time and watch it's output in the
"Debug Console" subpage. Some commands are even implemented that way,
for example adding a breakpoint simply opens the CL dialog with
"-break-insert <file>:<line>", and lets you specify any other options.
> One tricky point I can see is: how to mix programmed and direct
> interaction with gdb whilst still keeping the tab symbol completion?
Don't know, but Geany auto-completion may be an option.
> And it looks like there are other rough edges to be worked out for this,
> e.g. with regards to program interruption (--exec-interrupt requiring some
> kind of asynchronous mode that I couldn't get working, ctrl-C not being
> passed on to the target).
A local -exec-interrupt simply emits SIGINT. In both debugger and
Scope, the signal is sent to Geany and eventually gdb, but not the
target. :) May be different for remote.
^C should be sent directly to the target terminal, for example with
Scope "Program Terminal -> Feed -> 3" (though right clicking a thread
and choosing "Interrupt" would be easier). If the target and gdb use
the same terminal, you won't be able to communicate with gdb properly.
More information about the Devel