From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.bugs Subject: bug#6716: 23.2; Setting `find-function-source-path' has no effect. Date: Tue, 27 Jul 2010 21:38:42 -0400 Message-ID: References: <874ofpqeiu.fsf@gmail.com> <87eiepe022.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1280282878 31389 80.91.229.12 (28 Jul 2010 02:07:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Jul 2010 02:07:58 +0000 (UTC) Cc: 6716@debbugs.gnu.org To: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 28 04:07:56 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Odw3n-0002mB-UK for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Jul 2010 04:07:56 +0200 Original-Received: from localhost ([127.0.0.1]:45353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Odw3m-0002vk-Gr for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jul 2010 22:07:54 -0400 Original-Received: from [140.186.70.92] (port=32908 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Odw3b-0002tm-Bt for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2010 22:07:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Odw3Z-0003gF-IK for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2010 22:07:42 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45557) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Odw3Z-0003gB-Ff for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2010 22:07:41 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Odvbp-0002mP-N4; Tue, 27 Jul 2010 21:39:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: MON KEY Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Jul 2010 01:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6716 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6716-submit@debbugs.gnu.org id=B6716.128028111610679 (code B ref 6716); Wed, 28 Jul 2010 01:39:01 +0000 Original-Received: (at 6716) by debbugs.gnu.org; 28 Jul 2010 01:38:36 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdvbP-0002mC-NB for submit@debbugs.gnu.org; Tue, 27 Jul 2010 21:38:36 -0400 Original-Received: from mail-wy0-f172.google.com ([74.125.82.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdvbN-0002m7-VT for 6716@debbugs.gnu.org; Tue, 27 Jul 2010 21:38:34 -0400 Original-Received: by wyb40 with SMTP id 40so3561658wyb.3 for <6716@debbugs.gnu.org>; Tue, 27 Jul 2010 18:38:42 -0700 (PDT) Original-Received: by 10.227.137.193 with SMTP id x1mr7981727wbt.80.1280281122698; Tue, 27 Jul 2010 18:38:42 -0700 (PDT) Original-Received: by 10.216.137.67 with HTTP; Tue, 27 Jul 2010 18:38:42 -0700 (PDT) In-Reply-To: <87eiepe022.fsf@gmail.com> X-Google-Sender-Auth: p54tPfKNGhweLQkgPR0WTjhIjUk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 27 Jul 2010 21:39:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:39016 Archived-At: On Tue, Jul 27, 2010 at 5:39 AM, =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec 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 featur= es >> 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') > =C5=A0t=C4=9Bp=C3=A1n -- /s_P\