Luke Gorrie luke@bluetail.com writes:
[...]
This seems to work very well. It's based on the seemingly reasonably assumption that if the definition of BAR started with "(define-foo bar ..." before then it probably still does now. The same trick is used for interactively compiled definitions.
I like the idea with the hint string. This should work pretty good, especially for stuff compiled with C-c C-c.
For this case it now just detects that the file is modified and falls back to regexp-based search, the same way e.g. the OpenMCL backend works. This seems to work pretty well. I also tweaked the regexps a bit, hopefully for the better.
Hmm... I think the old approach wasn't too bad in this case. CMUCL's form numbers are relatively robust against modifications inside toplevel forms and inserting comments at the toplevel. The location is wrong only if a toplevel form is inserted or deleted before the form we need to find. This is something like 50% of the modifications at toplevel and if it fails, it is usually only 1 or 2 forms a away from the correct place.
The regexp variant can be completely wrong. E.g. it gets confused by block comments like #| (defun foo ..) |# or if there are two variants of the same function preceded with reader conditionals, like #+x86 and #+sparc. Regexps are currently almost useless to locate methods.
I liked the old variant better than the regexp stuff.
Perhaps a combined method would give the best results. First jump to the place as determined by the form numbers and then make a plausibility check with a regexp search before and after that place.
If problems persist then please let us know!
I've problems with C-u M-. compile. Point is placed before compile-component. This is probably just a too permissive regexp.
It will be interesting to see how this works for non-toplevel forms, as needed by the debugger.
Helmut.