166 |
Djurfeldt's guileint interface, but the end result will look quite |
Djurfeldt's guileint interface, but the end result will look quite |
167 |
different from that, I think. |
different from that, I think. |
168 |
|
|
169 |
|
The following subsections describe some of the ideas that I have in |
170 |
|
mind. |
171 |
|
|
172 |
|
4.3.1. Tracking the relationship between Scheme source buffers and the |
173 |
|
application they are relevant to |
174 |
|
|
175 |
|
[This idea comes from guileint.] |
176 |
|
|
177 |
|
Suppose a debugged application hits an error, and Emacs pops up a |
178 |
|
buffer displaying the source code for the error location. If the user |
179 |
|
edits and then wants to reevaluate part of that source code, the |
180 |
|
frontend should know that the application to send the evaluation to is |
181 |
|
the one that just hit the error. |
182 |
|
|
183 |
|
Then there is the case where the edit is in a file not yet known by |
184 |
|
the frontend to be associated with the application ... |
185 |
|
|
186 |
|
Getting the associated application is ultimately a heuristic effort. |
187 |
|
Therefore the goal is not to implement something provably correct, but |
188 |
|
to guess helpfully what the user wants 90% of the time, provide useful |
189 |
|
cues as to what the frontend is guessing, and make it equally easy for |
190 |
|
the user to go with the guess and to override it. |
191 |
|
|
192 |
|
4.3.2. Enhanced Scheme buffer editing |
193 |
|
|
194 |
|
[This idea comes from guileint.] |
195 |
|
|
196 |
|
Enhanced editing helps the user by keeping track of which top level |
197 |
|
forms have been edited since they were last evaluated by the |
198 |
|
associated application, and provides a convenient `reevaluate all |
199 |
|
edited forms' command. |
200 |
|
|
201 |
|
It also remembers, for each top level form, what the result of the |
202 |
|
last evaluation was. |
203 |
|
|
204 |
|
It also detects when a top level form is syntactically broken - |
205 |
|
i.e. its parentheses don't balance. Broken forms are excluded from |
206 |
|
the `reevaluate all edited forms' command. |
207 |
|
|
208 |
|
Finally, it visually indicates the current state of each top level |
209 |
|
form, which is one of `up to date', `edited' or `broken'. |
210 |
|
|
211 |
|
4.3.3. Application and module browsing |
212 |
|
|
213 |
|
This is a tree-like display of: |
214 |
|
|
215 |
|
Applications |
216 |
|
Modules (used by each application) |
217 |
|
Bindings (of each module) |
218 |
|
|
219 |
|
It can be used to: |
220 |
|
- set and configure breakpoints |
221 |
|
- see the current value of a binding |
222 |
|
- see the documentation for a binding. |
223 |
|
|
224 |
|
There are several possible methods for getting the list of modules for |
225 |
|
an application, and the list of bindings for a module, from static |
226 |
|
scanning to actually loading or running the code and seeing what |
227 |
|
results. The desirability and safety of each method depends on the |
228 |
|
code itself and is difficult to determine heuristically, so the |
229 |
|
frontend simply provides all the available options and leaves the |
230 |
|
choice up to the user. (Perhaps defaulting to a safe static scan.) |
231 |
|
|
232 |
|
I think it would be good to implement this as a specialized kind of |
233 |
|
Speedbar, to avoid completely reinventing the wheel. |
234 |
|
|
235 |
|
4.3.4. Error location and stack display |
236 |
|
|
237 |
|
[This idea comes from guileint.] |
238 |
|
|
239 |
|
When an error or breakpoint is hit, the frontend displays, in 3 |
240 |
|
windows: |
241 |
|
- the relevant source code |
242 |
|
- the stack |
243 |
|
- the error or breakpoint details. |
244 |
|
|
245 |
|
At such times, the frontend provides convenience commands for |
246 |
|
exploring the stack, evaluating variables, single stepping, continuing |
247 |
|
execution and whatever else is useful. |
248 |
|
|
249 |
|
4.3.5. Debug session recording and replay |
250 |
|
|
251 |
|
One disadvantage of a graphical interface is that it can be difficult |
252 |
|
to keep a log of actions performed and to repeat actions if necessary. |
253 |
|
The Emacs frontend remedies this by keeping a record of actions |
254 |
|
performed, on a per-application basis, and making it possible to |
255 |
|
replay them. |
256 |
|
|
257 |
4.4. Debugging channel protocol |
4.4. Debugging channel protocol |
258 |
|
|
259 |
(name NAME) |
(name NAME) |