From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file' Date: Sat, 4 Jul 2015 11:20:05 -0700 (PDT) Message-ID: References: <> <<83615zyiuq.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1436034090 6681 80.91.229.3 (4 Jul 2015 18:21:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jul 2015 18:21:30 +0000 (UTC) Cc: 20968@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 04 20:21:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZBS3t-0007e1-AS for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Jul 2015 20:21:13 +0200 Original-Received: from localhost ([::1]:44986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZBS3s-0000iK-69 for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Jul 2015 14:21:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZBS3n-0000hU-Vc for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2015 14:21:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZBS3j-0003eZ-Ll for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2015 14:21:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZBS3j-0003e6-GO for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2015 14:21:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZBS3i-0003SB-W5 for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2015 14:21:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jul 2015 18:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20968 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20968-submit@debbugs.gnu.org id=B20968.143603402513206 (code B ref 20968); Sat, 04 Jul 2015 18:21:02 +0000 Original-Received: (at 20968) by debbugs.gnu.org; 4 Jul 2015 18:20:25 +0000 Original-Received: from localhost ([127.0.0.1]:39903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZBS36-0003Qv-4w for submit@debbugs.gnu.org; Sat, 04 Jul 2015 14:20:25 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:40463) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZBS32-0003Qc-Dq for 20968@debbugs.gnu.org; Sat, 04 Jul 2015 14:20:21 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t64IKDTS015943 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Jul 2015 18:20:13 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t64IKCA7022456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 Jul 2015 18:20:12 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t64IKCgc007335; Sat, 4 Jul 2015 18:20:12 GMT In-Reply-To: <<83615zyiuq.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:104703 Archived-At: > > > One reason is to be able to use "M-x load-library RET", and have > > > it DTRT. If the *.elc files are separate from *.el, then at best > > > the problem of deciding which version to load becomes harder and the > > > loading becomes slower, and at worst you'll have a subtle bug on > > > your hands. E.g., what if more than one directory on load-path > > > has a file that goes by the same name? And in what order do you > > > search load-path for the companion .el file, given that you found > > > .elc in in some directory? > > > > It can of course happen that someone is confused, doesn't know how > > `load-library' works, and doesn't get the behavior that s?he > > mistakenly expected. > > > > But AFAIK, the behavior is well-defined. >=20 > It's well-defined only for the current behavior, where the *.el and > the corresponding *.elc files live in the same directory. How so? Please give a concrete example where it is not well-defined for a foo.el and a foo.elc that are in different directories. Explain what problems you think arise in such a case. > > Ordering multiple dirs in `load-path' is a way to control which > > version of a library gets loaded (whether .el or .elc gets loaded, > > and which .el or .elc gets loaded). >=20 > Users will get to manage the resulting complexity. I bet the OP > didn't even understand what kind of hole he is digging for himself. Who knows what the OP or other users might know? Your point here seems to be that even if the behavior is well-defined some users might find it confusing. Which is exactly what I already acknowledged: It can of course happen that someone is confused, doesn't know how `load-library' works, and doesn't get the behavior that s?he mistakenly expected. > There's a limit where more becomes less. Vague platitude, I'm afraid. Please point to a specific problem, if you expect us to make headway here in understanding. > > So unless I'm missing something, I see no good argument against > > the suggestion when it comes to `load-library'. >=20 > You see it, you just disagree with it. I see (and already acknowledged) the possibility of a user, given the additional control this provides, getting confused. I have not seen any other concrete argument. There are plenty of places in Emacs where we give users enough rope to hang themselves with. `load-path' already presents plenty of such opportunity. I don't see this enhancement as adding anything particular to the possible confusion - someone confused by what it offers is very likely confused about `load-path' behavior in general. I don't think this changes *anything* wrt `load-path' or the current code that handles it. You can already put .el and .elc wherever you like, in the same dir, in separate dirs, mix&match - whatever. You hand-wave about there being some problem with `load-library' that would make the behavior ill-defined. If you can show that with an example, perhaps I will agree with you. I really have no need for the suggested enhancement, myself, and no axe to grind about this. So far, it sounds to me like a reasonable request, but I welcome you to provide an argument to the contrary. > > > Last, but not least: the current implementation of loading a > > > Lisp file is a 2-level loop, where the outer one loops over > > > the directories, and the inner one over the suffixes. > > > > Which means that if there is only one suffix in a given directory > > then the inner one becomes a trivial case, no? >=20 > ??? Are you saying we will no longer allow both *.el and *.elc, only > one of them? Did I say anything even vaguely suggesting such a thing? Please try to calm down. Your argument is (as near as I can tell) that, because there is a two-level loop, an enhancement that would let users automatically place *.elc in a separate directory would be problematic and would require changes in the C code. You say nothing concrete about this. I can only assume that you think it is a problem for the *current* code to process multiple directories in `load-path', which might have different .el or .elc files with the same (relative) file names. I'm not aware of any such problem. I think the code already handles all such cases, regardless of where the .el and .elc files might be located. But as you know, I'm no expert in any of this, and I am especially ignorant of the C code. The case of the OP would put .el in one dir and .elc in another. S?he would have to decide which of the two dirs, or both, to add to `load-path' (and if both, in which order). But in any case, I see no problem or need for C code changes. Can you please point out just what the problems are? > > > So this suggestion, if implemented, will need C-level changes > > > as well. > > > > I trust your estimation of that, but I don't understand why it > > would be the case. >=20 > See above. See above. All I see is hand-waving, so far, I'm afraid. But I welcome a concrete example and explanation of the problem it poses for the current code.