GNU bug report logs - #6716
23.2; Setting `find-function-source-path' has no effect.

Previous Next

Full log

Message #29 received at 6716 <at> debbugs.gnu.org (full text, mbox):

From: Štěpán Němec <stepnem <at> gmail.com>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 6716 <at> debbugs.gnu.org
Subject: Re: bug#6716: 23.2; Setting `find-function-source-path' has no effect.
Date: Tue, 27 Jul 2010 11:39:01 +0200

MON KEY <monkey <at> sandpframing.com> writes:

> bug#6716: 23.2; Setting `find-function-source-path' has no effect.
>
> ,---- SM worte:
> | Also, it may not work for files that were loaded as "foo/bar".  I
> | think the load-history needs to be changed to keep track of both the
> | absolute file name and the name used to load the file
> | (i.e. "/bla/bla/foo/bar.elc" and "foo/bar").
> |
> | Then in find-function-source-path we will first try for
> | /bla/bla/foo/bar.el and when that fails we can fall back on searching
> | for foo/bar.el.
> `----
>
> ,---- SN wrote:
> | When you look at the current `find-library-name' definition, it's
> | _obviously_ wrong to pass an absolute file name to it. It just makes no
> | sense.
> `----
>
> IMHO this type of problem has less to do w/ the path handling of
> `find-library-name' and `locate-file's and more to do w/ how these
> (and related procedures) find/frob file-name suffixes on a given path
> e.g. the +real+ problem is with how Emacs plays with these:
>
> `find-library-suffixes', `get-load-suffixes', `load-file-rep-suffixes'
>
> FWIW Štěpán it may be useful to look at this thread here:
>
> :SEE
> (URL `http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01060.html')

Thank you, but I think you misunderstood. The problem at hand (in this
bug report) _is_ the problem with how `find-library-name' handles paths;
I don't see any problem with the suffixes as in your bug report.

As I wrote in the mail you quote above, `find-library-name' passes an
absolute pathname to `locate-file', which makes no sense. That's the
basic symptom of what needs to be cured (although as Stefan points out,
simply removing the path component is probably not the right solution);
it has nothing to do with {find-library,get-load,load-file-rep}-suffixes
or file name completion.

> My impression is that Stefan's file completion regime is brittle w/re
> this type of stuff... hence his (understandable) hesitancy to make any
> dramatic changes/modifications/tweaks.
>
> WIBN if Emacs lisp could treat namestrings as "Lisp Type" objects as
> opposed to "Unix/C Type" objects? I.e. something like Common Lisp's more
> CLOS centric handlers:
>
> `namestring'
> `directory-namestring'
> `host-namestring'
> `parse-namestring'
> `file-namestring'
> `pathname'
> `pathname-name'
> `pathname-type'
> `pathname-directory'
> `truename'
> `make-pathname'
> `merge-pathnames'
> `enough-namestring'
>
> :SEE (URL `http://www.lispworks.com/documentation/lw50/CLHS/Body/19_ab.htm')
>
> Stefan, how reasaonable/welcome would it be to dovetail the EIEIO features
> with C primitives to accomplish something like what CL offers ITR?

Wouldn't it be better to discuss this on emacs-devel or file another bug
report? I really don't see any relation here.

  Štěpán

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.