-var-evaluate-expression reports the value from the last -var-update or
-var-assign execution, not the current value

register modified is 07 since changing a register ($dh, $mm1.uint64) may
change another ($dx, $st1), and there is some chance of watches/inspects
containing a register

07<scid>-var-assign is required, because assigning to an out of scope
(sub)variable may succeed(?), but not be reflected on -var-update *

the only way to fix unnecessary inspect drop target expansion is to block
INTO, so deriving GtkTreeStore and altering GtkTreeDragDest makes no sense

"new_children: If new children were added to a dynamic varobj [...]"
"A varobj's contents may be provided by a Python-based pretty-printer
In this case the varobj is known as a dynamic varobj" - not supported

shift-clicking send/busy to send a command without closing the dialog can be
implemented, but will be ugly; shortcut for "GDB command" plus typing in the
debug console should suffice

gtk tooltips send lots of queries, and can't be explicitly shown/hidden;
sci dwell tips often do not disappear as they should; tooltip_update_state
can not be used, because sending the tooltip evaluate command changes state

under win~1, the async break messages escape all slashes twice; file names
can be handled, but other fields (condition, script) choke parser

under win~1, if Geany is compiled with -mconsole, gdb stdin/stdout will be
mixed with the program stdin/stdout, leading to gigo

in foreground execution, GDB waits for the program to report that _some_
thread has stopped before prompting for another command

clicking a button with response 0, and then clicking an accept button or
gtk_dialog_response(ACCEPT), may generate 0 instead of accept

-var-create for global symbols allows any frame
-set-update-range seems to have no effect on my system

global objects may be evaluated (including as variable objects) in hang
state, but modification requires running inferior

parse with string in VR_COMPACT / VR_NEUTRAL is slower for texts with less
than 100 characters, but with such shorts texts, the difference is
insignificant; for large texts, using string is faster, but not much

CPU load on F8 with vte console: ~88%
with context: ~80%, null output: ~75%

GtkTextView with wrapping CHAR: the last character of a wrapped line can be
selected with the mouse only by moving to the next line

Geany gtk+2 under Win~1, with FF also running, eats 7-8% CPU time, other
applications/conditions may cause such CPU load too; scope doesn't matter

http://sourceware.org/bugzilla/show_bug.cgi?id=9659

set print array on: "  {1,\n  2,\n  3}"
set print array-indexes on: "{[0] = 1, [1] = 2, [2] = 3}"
set print elements 10: "\a01\002\003\004\005\006\a\b\t\n"...
	{290, 291, 292, 293, 294, 295, 296, 297, 298, 299...}
'\000' <repeats 100 times>, '\001' <repeats 100 times>

pending breakpoints are handled either at thread stopped, or by async
modified message; parsing =library-loaded seems pointless

geany->app->datadir = /usr/local/share/geany
geany->app->docdir = /usr/local/share/doc/geany/html

		break	trace			watch

disabled	-d	-d			-break-disable
condition	-c	-c			-break-cond
count		-i	-break-passcount	-break-after

script = -break-commands
fast trace = -break-insert -a -h

" " is valid executable name, but not valid source name - gdb requires
certain suffixes (.c .c++ etc.); thus we can validate_column(file, TRUE)

project open: scope message, then geany open message
project close: geany close message, then scope message

gdb manual states that "which commands will work in the context of a running
thread is highly target dependent", but "commands that try to operate on
thread's stack will not work, on any target"; some commands are DS_SENDABLE
or DS_NOT_BUSY, even if unlikely to execute (like a global watchpoint)

scid is required because all list positions are async-gdb-output volatile

break filename may be specified as known source name (test.c) or absolute
name (/home/build/test.c); neither inferior nor gdb relative names work

would be nice to have 02-thread-info to fully refresh the thread list, if we
missed a thread message, but needs some effort, and we compute gdb status
(and send commands) based on threads, so that'll be very tricky

gdb recommends full refresh after error, but at least the errors from
refresh (04) commands errors must be ignored avoid an endless loop

applying break/watchpoints to a thread is promlematic: -break-list does not
contain such info, and the thread identifiers are different on restart

tested with "unsuccessful" program pty creation - no idea where the terminal
I/O comes from or goes to

we don't reload terminal prefs on save settings since the signal is before
save and they are they are either empty (for new .conf file) or old

scite mark "arrow" is actually triangle

--all | --thread-group N commands:
	-exec-continue
	-exec-interrupt
	-exec-run

"If the `--thread-group' options is specified, then all threads in that
thread group are resumed."

*stopped "all" means from this group or everything?

running "all" does not specify a thread/group; the first running is "all",
others are thread - but that's from observation, gdb.info says nothing
