Re: `dir'

[Tom Tromey <tromey at cygnus dot com>]

Jim> On the one hand, you are right, it is better to have the hook as
Jim> close to where the change happens as possible, so that you get
Jim> consistent responses to the change no matter how it is affected.
Jim> On the other hand, to really track the command line, you may end
Jim> up sprinkling so many hooks all over the gdb code that it gets
Jim> cumbersome & ugly.

Yeah.  This would be easier if gdb had a nicer internal factoring, but
then, so would many things.

Jim> If you had a "run this tcl proc on each CLI command" mechanism,
Jim> picking up a place where you were not tracking the gui properly
Jim> and fixing it would be really trivial

I have a vague concern about performance here, but that probably isn't
serious.

At my last job I implemented an advice package for Tcl.  Hey... I
almost forgot, I reimplemented it in libgui as well.  The idea is that
you can attach random functions to run before or after other
functions.

This is really handy for debugging.  For other things it doesn't work
as well, because your advisee has to track the usage of the advisor --
and this relationship isn't explicit.  You just wind up with a runtime
error if the changes are out of sync.

For the "directory" command the problem doesn't occur -- no matter how
"directory" was invoked, you just re-examine the source cache.  But
for other commands, the behavior depends on the arguments, and you
have to be smart about examining them from Tcl.  To me this sounds
like a big maintenance problem -- and my experience using advice in my
previous job shows that it is.  In the end we decided that we would
*only* use advice to debug, and instead added explicit, documented
hooks (whose calling conventions were documented too) whenever state
notification was needed.

Tom