Re: `dir'

[James Ingham <jingham at cygnus dot com>]

Tom,

 > Jim> But I was poking my nose in libgui, and noted the tantelizing
 > Jim> tclgetdir.c file...
 > 
 > Another wonderful piece of Foundry technology lives on!  Thanks, IanT.
 > Note that on Unix this works by using a hacked tk_getOpenFile.  I
 > don't know if those hacks are in the Insight Tk.
 > 
 > Jim> I am more likely to add the GUI, and have that do the right
 > Jim> thing, than add another hook to the CL.  Actually, it would be
 > Jim> nice to just have a generic pre or post processing hook in ALL
 > Jim> the commands executed by the gdb command interpreter, so you
 > Jim> wouldn't have to go add the hooks into the C code to do this sort
 > Jim> of thing.
 > 
 > My feeling is that what you really want is a way to be notified by the
 > gdb core when interesting state changes.  The GUI would run the "dir"
 > command, but would rely on this same notification to update the source
 > window cache.
 > 
 > You want this because then it doesn't matter how the state changes --
 > only that it has changed.
 > 
 > Whether this is done by hooking into the command interpreter in a
 > generic way, or more directly into the core (e.g. in this case in
 > directory_command()), I don't know.

Yeah, I am of two minds about this.  On the one hand, you are right,
it is better to have the hook as close to where the change happens as
possible, so that you get consistent responses to the change no matter 
how it is affected.  On the other hand, to really track the command
line, you may end up sprinkling so many hooks all over the gdb code
that it gets cumbersome & ugly.  If you had a "run this tcl proc on
each CLI command" mechanism, picking up a place where you were not
tracking the gui properly and fixing it would be really trivial, just
add another pattern to your command hook, and write the Tcl code to
respond... 

I am not altogether sure.

Jim