Re: lisp-find-file returns the wrong buffer, plus M-. aside

   From: Marco Antoniotti <[email protected]>
   Date: Tue, 27 Aug 2002 09:29:59 -0400

   Thanks.  This looks good.

Great; glad to hear it passes muster.

   BTW.  On a somewhat unrelated note: does anybody know of a `etags'
   program capable of dealing with generic functions and methods?

   Cheers

I'm not aware of any.  I think the fundamental problem is that CLOS
methods have hairy compound names that do not appear in any form in the
source.  (I wonder what C++ users do.)

   However, this strikes me as more of a problem within emacs than with
the etags program itself.  You can use "--regex='(defmethod'" to put the
definitions in your TAGS file, but then you are stuck with visiting
every method even if you only want to find a particular one.  (Come to
think of it, I bet that's what the C++ world puts up with.)

   But finding methods happens to be the issue that set me off on my
"quest" to improve M-., so allow me to expand a bit on what I have so
far.  The approach I am taking requires "widening the pipe" from the
Lisp, and narrowing the search for specific definitions within emacs:

   1.  When given a generic function name, the Lisp enumerates and
returns the names and source files of all methods, preceded with the
name and source file of the defgeneric form, if any.  The existing code
just enumerates the methods' source files, which isn't terribly useful
without knowing the method names.  The definition and file names are put
into the *Edit-Definitions* buffer so that the user can easily view,
edit, and randomly access them.  (See below for an example.)

   2.  When finding a method definition, ilisp therefore has the full
method name as known to the Lisp.  That makes it possible to construct a
very specific regular expression to find only that method, which is used
to search only that file.  This in turn makes random access of the
*Edit-Definitions* buffer useful.

   Rather than making regexps do all the work, it seems to me, it would
be better to just search for "(defmethod <generic-fn-name>" with a
suitably robust regexp, and then ask the Lisp whether this is the right
definition.  This soaks up somewhat more Lisp bandwidth, but has the
advantage of being able to deal with package ambiguities and reader
conditionalization within the arglist.  I haven't yet decided whether
it's worth the trouble.  But I expect it would reduce the possibility of
false negatives, so it probably ought to be done.

   The enumeration of GF methods is just a special case of returning
source locations for all matching definitions associated with the
symbol, e.g. variables, functions, CLOS classes, etc.  As a result, the
"any" definition type now really means "all", and is more featureful.
(I notice that looking for "any" using the current ilisp release often
blows out the regexp stack in emacs 20.7, presumably because it is
trying to search for all possible definitions of a symbol in parallel.
This is not necessary when emacs gets (name type file) triples handed to
it on a silver platter.)  Consequently, I've made "any" the default.

   Because of this, edit-definitions-lisp now omits the prompt for the
definition type if can find only one, as should be the case for most
definitions in user code.  A generic function with a single method is
now found as easily via the GF name as if it were a defun, which
conceptually it is.

   All of which makes my personal M-left-click hack work like
gangbusters on CLOS code.  Which brings us full circle to my motivation
to work on this.

   My apologies for the long screed; I really need to write some patch
notes . . .

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

*----------------------------------------------------------------------*
Here is an example of the contents of *Edit-Definitions* after doing
"M-. describe-object RET" while talking to CMUCL 18d:

    ;; any describe-object definitions:

    ;; DESCRIBE-OBJECT is a generic function with 7 methods.
    :Generic-Function DESCRIBE-OBJECT in file /prj/cmucl/release-18d/linux/pcl/env.x86f
    :Function (METHOD DESCRIBE-OBJECT (HASH-TABLE T)) in file /prj/cmucl/release-18d/linux/pcl/env.x86f
    :Function (METHOD DESCRIBE-OBJECT (PACKAGE T)) in file /prj/cmucl/release-18d/linux/pcl/env.x86f
    :Function (METHOD DESCRIBE-OBJECT (PCL::CLASS T)) in file /prj/cmucl/release-18d/linux/pcl/env.x86f
    :Function (METHOD DESCRIBE-OBJECT (STANDARD-GENERIC-FUNCTION T)) in file /prj/cmucl/release-18d/linux/pcl/env.x86f
    :Function (METHOD DESCRIBE-OBJECT (PCL::SLOT-OBJECT T)) in file /prj/cmucl/release-18d/linux/pcl/env.x86f
    :Function (METHOD DESCRIBE-OBJECT (T T)) in file /prj/cmucl/release-18d/linux/pcl/env.x86f
    :Function (METHOD DESCRIBE-OBJECT (PCL::CONSTRUCTOR T)) in file /prj/cmucl/release-18d/linux/pcl/construct.x86f

For compatibility, this format is also produced if the Lisp returns a
list of pathname strings, which is what Lisps that don't have the new
"wide pipe" code will do.

   [Unfortunately, it seems that PCL stores physical pathnames when it
compiles itself, and not logical or search-list pathnames.  So the
'ilisp-source-directory-fixup-alist' feature will need to remain with us
for the time being.]

   [Speaking of which, the documentation for
ilisp-source-directory-fixup-alist conflicts with the implementation; it
says the that cdr of each alist entry should be a function, but
fix-source-filenames insists on having a string.  I figure I might as
well support both; it's easy enough.]


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390