[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Grand Unified Debugger Rewrite's process buffer: comint, eterm or es
Re: Grand Unified Debugger Rewrite's process buffer: comint, eterm or eshell?
Fri, 6 Nov 2009 19:22:20 -0500
On Fri, Nov 6, 2009 at 4:49 PM, Nick Roberts <address@hidden>
> Another thing you might want to consider in the design is to allowThis is not such a good idea. The user migh actuallyt want to edit his source
> debugger interaction with simple key bindings from file buffers.
> Now to send commands to the debugger you'd have to use the *gud* buffer,
> or use complicated key bindings.
> Compare to how `edebug' works, the buffer is made read-only, and simple
> bindings like: n c d can be used.
code during a debug session.
Anders allows for toggling that mode. Again see the code sited for details.
I found myself toggling it all the time to turn it off. That's the
point at which I realized, that the underneath support was really
lacking. So in my opinion it was pointless to pursue this until the
fundamentals were fixed up.
Previously in this thread I mentioned that gud uses a cons node
(filename . line-number) to store a position. I have now use a struct
which contains a marker plus the source location position reported.
That way I can know not only that the file has changed (and this is
not to be the only such way), but also by checking all markers of a
buffer for a given debugger session against their source location
information, I can get a rough idea of how other lines may have changed
relative to what the source location reported in the location structs.
Admittedly to do all of this is pretty heavy coding even if it is
language and debugger independent. But at least with these fundamentals
doing this is conceivable while with gud, it isn't.