From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: =?UTF-8?B?UmU6IFtCVUddIGBvcmctbG9hZC1ub2Vycm9yLW11c3RzdWZmaXg=?= =?UTF-8?B?wrQgaXMgbm90IGRlZmluZWQsIGludHJvZHVjZWQgYnkgNTQ4NGEzM2I=?= Date: Fri, 11 Jan 2013 13:19:21 -0700 Message-ID: <87zk0fwjzq.fsf@gmail.com> 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> <87fw27cybb.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:43933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttl4t-0006sl-Gg for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 15:19:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ttl4m-00047x-9p for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 15:19:47 -0500 Received: from mail-ie0-f170.google.com ([209.85.223.170]:40995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttl4m-00047f-45 for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 15:19:40 -0500 Received: by mail-ie0-f170.google.com with SMTP id k10so2846122iea.15 for ; Fri, 11 Jan 2013 12:19:37 -0800 (PST) In-Reply-To: <87fw27cybb.fsf@Rainer.invalid> (Achim Gratz's message of "Fri, 11 Jan 2013 20:30:16 +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: Achim Gratz Cc: emacs-orgmode@gnu.org Achim Gratz writes: > 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) > =3D> find-func > (find-library-name "org-loaddefs.el") > =3D> "/usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el" > (add-to-list 'load-path "~/lisp/org-mode/lisp") > =3D> (~/lisp/org-mode/lisp =E2=80=A6) > (find-library-name "org-loaddefs.el") > "/home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz" > (load "org-loaddefs.el" t nil t) > =3D> 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")) > =3D> Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz... > =3D> uncompressing org-loaddefs.el.gz...done > =3D> 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). > > [=E2=80=A6] >> 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. > These sounds like a Emacs-wide (or possibly find-library) issues, rather than anything specific to Org, outlining, agendas or plain text notes. Shouldn't this sort of discussion and development be taking place on emacs-dev and in non-org Emacs libraries. In my opinion the only reason to try to solve these issues in Org-mode proper is if we are testing out new functionality which will eventually be adopted by core Emacs. Otherwise I would argue that such development within Org-mode is a waste of Org-mode development time, effort and code complexity. At the least perhaps such load/require mechanisms should be extracted into a separate library with no Org-mode specific code. Then Org-mode could make use of these libraries, but so could other large systems distributed with Emacs but developed independently (e.g., gnus). Best, --=20 Eric Schulte http://cs.unm.edu/~eschulte