[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grand Unified Debugger Rewrite's process buffer: comint, eterm or es

From: Rocky Bernstein
Subject: Re: Grand Unified Debugger Rewrite's process buffer: comint, eterm or eshell?
Date: Fri, 6 Nov 2009 19:22:20 -0500

On Fri, Nov 6, 2009 at 4:49 PM, Nick Roberts <address@hidden> wrote:
 > Another thing you might want to consider in the design is to allow
 > 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.

This is not such a good idea.  The user migh actuallyt want to edit his source
code during a debug session.
Anders allows for toggling that mode. Again see the code sited for details.

Personally 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.

Nick                                           http://users.snap.net.nz/~nickrob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]