From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: =?UTF-8?B?UmU6IFtCVUddIGBvcmctbG9hZC1ub2Vycm9yLW11c3RzdWZmaXg=?= =?UTF-8?B?wrQgaXMgbm90IGRlZmluZWQsIGludHJvZHVjZWQgYnkgNTQ4NGEzM2I=?= Date: Fri, 11 Jan 2013 20:30:16 +0100 Message-ID: <87fw27cybb.fsf@Rainer.invalid> References: <87a9sh3tsp.fsf@gmail.com> <877gnlknlx.fsf@bzg.ath.cx> <87sj69ro12.fsf@gmail.com> <87pq1dj76n.fsf@bzg.ath.cx> <87hamprlob.fsf@gmail.com> <11306.1357839845@alphaville> <874niosy6w.fsf@gmail.com> <87txqodgix.fsf@bzg.ath.cx> <87txqovnv3.fsf@gmail.com> <874niodcry.fsf@bzg.ath.cx> <87vcb4spxe.fsf@gmail.com> <8738y8n0b2.fsf@gmail.com> <87lic0bpwj.fsf@bzg.ath.cx> <87hamo7gdk.fsf@gmail.com> <87wqvk9p5f.fsf@bzg.ath.cx> <87ehhrhpjl.fsf@bzg.ath.cx> <87sj67d662.fsf@Rainer.invalid> <87a9sf1wsl.fsf@bzg.ath.cx> <87k3rjd51k.fsf@Rainer.invalid> <87obgvzlah.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:35092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtkJJ-0000yT-GA for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 14:30:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtkJA-00088v-H9 for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 14:30:37 -0500 Received: from plane.gmane.org ([80.91.229.3]:37731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtkJA-00088r-AE for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 14:30:28 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TtkJO-00079W-Dy for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 20:30:42 +0100 Received: from pd9eb573f.dip.t-dialin.net ([217.235.87.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jan 2013 20:30:42 +0100 Received: from Stromeko by pd9eb573f.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jan 2013 20:30:42 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Bastien writes: > Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and > not ".elc" files, right? My question is: when is it necessary? The 'mustsuffix argument prevents consideration of the filename without the extensions listed in load-suffixes. In other words, when you are trying to load feature 'x, a file named just "x" does not satisfy the requirement as it otherwise would. On the other hand, it does not prevent using "x.el.gz" instead of "x.el" as 'nosuffix does. > I'm trying to consider real use-cases, with a sense of "real" close to > "not so improbable". I don't see why Org should take care of users > who are pervert enough to gzip their org-loaddefs.el... but maybe I > lack imagination, as usual :) This is a real use case. Installation with compression is a standard feature of Emacs and just currently not supported by the build system, mainly due to "little" problems like the above. Emacs' current installer itself compresses the source files only when there's a byte-compiled file around, so any recent Emacs would automatically have a file "org-loaddefs.el" in load-path, although some packagers have their own ideas about this. You should generally expect that the installed files, whether sources or byte-compiled files could have been compressed. Now if someone decides to compress the lisp folder for their own org installation and aren't taking care to exclude the autoload files, then this is what they get from 'emacs -Q": --8<---------------cut here---------------start------------->8--- (require 'find-func) => find-func (find-library-name "org-loaddefs.el") => "/usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el" (add-to-list 'load-path "~/lisp/org-mode/lisp") => (~/lisp/org-mode/lisp …) (find-library-name "org-loaddefs.el") "/home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz" (load "org-loaddefs.el" t nil t) => Loading /usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el (source)...done --8<---------------cut here---------------end--------------->8--- This is decidedly not what you wanted to achieve and outright devious, given that you don't even get the hint from *Messages* what file actually got loaded when the second argument to load is also "t". --8<---------------cut here---------------start------------->8--- (require 'org-macs) (let ((load-suffixes (list ".el"))) (org-load-noerror-mustsuffix "org-loaddefs")) => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz... => uncompressing org-loaddefs.el.gz...done => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz...done --8<---------------cut here---------------end--------------->8--- This on the other hand is what was intended to happen. The problem is that for the previous discussion "(require 'org-macs)" was effectively a NOP because 'org-macs was already loaded from a different place. If you want to fix it, then that's where the effort should be directed (org-reload already does that and it's not difficult to do here either). […] > But I know your answer, `find-library' does not give the library from > which functions have been autoloaded. I might harp too much about this, but it's not the answer to this question. But see above how find-library can fool you when you are actually using load with optional arguments instead. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves