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

[MON KEY <monkey@sandpframing.com>]

On Tue, Jul 27, 2010 at 5:39 AM, Štěpán Němec <stepnem@gmail.com> wrote:
,----
| As I wrote in the mail you quote above, `find-library-name' passes an
| absolute pathname to `locate-file', which makes no sense.
`----

Maybe, but but only if/when viewed out of the context of other closely
related (and often tightly coupled) features.

Sorry, but you can't "fix" find-library-name w/out tweaking
`locate-file' and that _can not_ happen without accounting for Emacs'
reliance on the `*-suffixes' vars/fncs.

,----
| basic symptom of what needs to be cured (although as Stefan points out,
| simply removing the path component is probably not the right solution);
`----

Damn Skippy. This is because the problem is also elsewhere (-:

,----
| it has nothing to do with {find-library,get-load,load-file-rep}-suffixes
| or file name completion.
`----

Well, assuming there can be a portable and non-backward-incompatible
fix for the symptoms you describe, I seriously doubt you will find it
w/out careful consideration of how the fix will affect these things.

Its not a simple matter of changing _only_ how pathnames (absolute or
otherwise) are handled.

here's an overview of the affected callers:

 find-library-name -> locate-file -> locate-file-internal

Profile these for a bit.

These are fundamental procedures. They do a fair degree of the primary
heavy lifting for a number of reliant satellite routines. Sooner or
later you'll find snags and weird corner cases where dependent
features will fail if they frob file namestrings in `load-history'
having extensions which rely on the return values of one or more of
the following:

`load-file-rep-suffixes'
`jka-compr-load-suffixes'
`load-suffixes'
`get-load-suffixes'
`load-history-regexp'

Of itself this isn't a problem _BUT_ it invariably becomes one as
soon as one attempts a meta-view towards fixing Emacs' approach to
file/dir traversal/searches. This is esp. so when one considers that
in the wild Emacsen are running on multiple different platforms.

Hence my reference to CL's file-system abstractions for filenames,
pathnames, namestrings, etc. for both logical and physical pathnames
as these were formulated with these types of problems in mind.

Right now Emacs is storing/accessing file "types" and "names" as well
as directories and pathnames (both logical and physical) across a
bewildering number of variables, constancts, custom-forms, functions,
subrs, and C primitives. A good majority of these objects are either
duplicate (and/or replicate with minor adaptation) an existing return
value or were otherwise implemented as a kludge to accommodate a
platform dependent file-system issue.

Many of these redundancies could/should be abstracted away by
establishing a more object-centric approach which +specifically+
address file-system frobbing and which relies less on string splitting
and regexps to manipulate file-system data-structures. Or, we could
just keep piling on more and more AWKish duct-tape...


>> 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
`----

Nah, they're too busy over there discussing how to improve Emacs'
learning curve.

,----
| I really don't see any relation here.
`----

There is one and it is more than tangential.

FWIW A good deal of Emacs' file-system fncns are Unix'ized versions
of CLTLv1 given a non-CLTLv1 name.

That no one really seems to acknowledge (or remember this) doesn't
mean it isn't so.

This is too bad because it blinds many to the reality of Greenspun's 10th:

 "Any sufficiently complicated C or Fortran program contains an ad hoc,
  informally-specified, bug-ridden, slow implementation of half of
  Common Lisp."

:SEE (URL `http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule')

>  Štěpán

--
/s_P\