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

[MON KEY <monkey@sandpframing.com>]

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')

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?

--
/s_P\