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

["Štěpán Němec" <stepnem@gmail.com>]

MON KEY <monkey@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