[Ilisp-devel] Re: [Ilisp-help] edit-definitions-lisp problems

[Bob R. <rog...@rg...>]

   From: Lynn Quam <qu...@AI...>
   Date: Thu, 18 Dec 2003 09:39:19 -0800

   Changing (setq lisp-edit-file nil) to (setq lisp-edit-files nil)
   fixed some problems, but I have isolated another problem related
   to setf methods.  Here is a test file . . .

   So, ILISP::SOURCE-FILE is doing the right thing, but
   LISP-FIND-NEXT-POSSIBILITY is losing.

I think I can reproduce this more-or-less reliably, by doing all of the
following:

   1.  Start a lisp (I tried both CMUCL and ACL, with similar results).

   2.  Load ilisp and your test case, in the manner prescribed.

   3.  In the Lisp buffer, do M-. on a nonexistent definition.  This has
the effect of flushing the cache, and forcing further communication with
the Lisp.

   4.  Still in the Lisp buffer, do M-. on "baz".  The exact means by
which M-. is invoked (keyboard, mouse, C-x ESC ESC) doesn't seem to
matter.

   5.  Repeat at step 3.

But I had such trouble that I'm not confident I found the same problem.
In any case, this allowed me to find a problem with the sit-for around
line 700 of the CVS version of ilisp-src.el.  The code looks like this:

		     (cond ((not back-p)
			     (message "%s" (match-string 1))
			     (sit-for 1)))

If I add a call to message to report the current buffer just before and
after this fragment (back-p is always false), I find it changes from
*Edit-Definitions* back to the Lisp buffer I started in, which certainly
explains why it wasn't finding any definitions.  I can only imagine that
the ilisp process filter is running during the sit-for interval, and it
somehow fails to preserve the current buffer.  So wrapping a
save-excursion around the sit-for ought to paper over the problem, but
is bloody ugly -- and besides, clearing up the real problem may fix
other intermittent bugs.  But I've run out of time for tracking it down
further.  I'll pick it up again tomorrow, but if anybody else has
suggestions in the mean time, I'd love to hear them.

   This problem appears to be specific to the setf methods.

   Doing M-. on FOO sucessfully finds the function definition for foo.

Yes and no; it's not about setf methods, but methods in general.  When
you M-. on BAR, and BAR is a macro or ordinary function name, or the
name of a generic function with an explicit defgeneric form, M-. takes
you right to it.  When BAR is a GF with only methods, M-. inserts a "BAR
is a GF with x methods" message in *Edit-Definitions* in order to advise
you that it has taken the liberty of expanding the interpretation of the
name you gave it.  Displaying this message is what triggers the fateful
sit-for.  (Assuming of course that we are really talking about the same
problem; please let me know if you find otherwise.)

					-- Bob Rogers
					   http://rgrjr.dyndns.org/