[slime-devel] More steroids for M-. in CMUCL

[Helmut Eller]

Luke Gorrie <luke at 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.