From: Bastien <bzg@altern.org>
To: Achim Gratz <Stromeko@nexgo.de>
Cc: 10125@debbugs.gnu.org
Subject: bug#10125: RFE: require and load-path-shadowing
Date: Sat, 12 Jan 2013 14:34:29 +0100 [thread overview]
Message-ID: <87hamm8qze.fsf@bzg.ath.cx> (raw)
In-Reply-To: <87ip72n1v7.fsf@Rainer.invalid> (Achim Gratz's message of "Sat, 12 Jan 2013 11:15:40 +0100")
Achim Gratz <Stromeko@nexgo.de> writes:
> Achim Gratz writes:
>> Stefan Monnier writes:
>>> Yes, this subroutine is never directly called from C, so placing an
>>> advice should work just fine.
I thought coding conventions prevented advising primitives?
I does not look clean to advise `require' here, just for Org.
> "Check whether a required feature has been shadowed by changing
> `load-path' after it has been loaded and reload that feature from
> current load-path in this case."
I don't understand why we need this.
This is at best a workaround to fix dirty installations.
I updated Org's installation process yesterday:
http://orgmode.org/org.html#Installation
I made it clear that the user, if she wants to install Org on top of
the pre-bundled version, must choose between on of the three methods.
For each method, I explain how to set up the load-path (if needed) and
org.el will load the correct org-loaddefs.el, resetting autoloads
correctly.
In org.el, no Org package is required before org-loaddefs.el is loaded.
> This takes care of a situation when Org is activated after some parts of
> it have already been loaded (maybe via autoload) and the load-path has
> been changed inbetween.
I don't see why this should happen. Setting the correct load-paths is
the first thing user should do in their .emacs.el.
--
Bastien
next prev parent reply other threads:[~2013-01-12 13:35 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87sj68eogm.fsf@Rainer.invalid>
[not found] ` <mthamoy574.fsf@fencepost.gnu.org>
2013-01-11 1:57 ` bug#10125: RFE: require and load-path-shadowing Stefan Monnier
[not found] ` <jwvvcb47bs0.fsf-monnier+emacs__21035.4545656175$1357869514$gmane$org@gnu.org>
2011-11-24 12:12 ` 24.0.91; package.el (org): Macros in tar packages & order of byte compilation Jambunathan K
2002-01-01 0:33 ` bug#10125: " Jambunathan K
2011-11-24 13:05 ` Eli Zaretskii
2011-11-24 17:22 ` Jambunathan K
2011-11-24 19:09 ` Glenn Morris
[not found] ` <v062i9tk0d.fsf@fencepost.gnu.org>
2011-11-24 19:53 ` Glenn Morris
2011-11-24 22:55 ` Stelian Iancu
2011-11-24 23:54 ` Glenn Morris
2011-11-25 3:31 ` Jambunathan K
2011-11-25 12:32 ` Stelian Iancu
[not found] ` <CAKvLAojUzYmrUF_64WXEbj9zmBjzZ4gn5cDYVqLTcik41PFJ7w@mail.gmail.com>
2011-11-25 12:58 ` Jambunathan K
2011-11-25 8:10 ` Eli Zaretskii
[not found] ` <hffwhdqov3.fsf@fencepost.gnu.org>
2011-11-25 12:15 ` Jambunathan K
2011-11-25 14:07 ` Chong Yidong
[not found] ` <87r50w47o3.fsf@gnu.org>
2011-11-25 14:57 ` Stefan Monnier
2011-11-25 19:15 ` Glenn Morris
2011-11-25 19:21 ` Glenn Morris
2011-11-25 18:19 ` Glenn Morris
2011-11-25 19:01 ` Glenn Morris
[not found] ` <83vcq88vwt.fsf@gnu.org>
2011-11-25 18:20 ` Glenn Morris
2013-01-11 16:06 ` bug#10125: RFE: require and load-path-shadowing Achim Gratz
[not found] ` <jwvvcb34qjg.fsf-monnier+emacs@gnu.org>
2013-01-11 16:56 ` Stefan Monnier
2013-01-11 19:53 ` Achim Gratz
2013-01-11 22:52 ` Stefan Monnier
[not found] ` <jwvlibz2v6e.fsf-monnier+emacs@gnu.org>
2013-01-12 8:15 ` Eli Zaretskii
2013-01-12 10:15 ` Achim Gratz
2013-01-12 13:34 ` Bastien [this message]
2013-01-12 14:03 ` Stefan Monnier
2013-01-12 14:23 ` Bastien
[not found] ` <87liby7a57.fsf@bzg.ath.cx>
2013-01-12 16:12 ` Stefan Monnier
2013-01-12 17:34 ` Bastien
2013-01-12 10:20 ` Achim Gratz
2013-01-12 12:07 ` Eli Zaretskii
2013-01-12 13:28 ` Stefan Monnier
[not found] ` <jwvehhqy1k8.fsf-monnier+emacs@gnu.org>
2013-01-12 13:55 ` Eli Zaretskii
[not found] ` <83wqvisdxx.fsf__30242.1131091707$1357998993$gmane$org@gnu.org>
[not found] ` <87ip72fi8f.fsf@Rainer.invalid>
2013-01-12 18:39 ` Eli Zaretskii
2013-01-12 18:42 ` Glenn Morris
[not found] ` <71vcb22qgz.fsf__38024.2966501557$1358016217$gmane$org@fencepost.gnu.org>
[not found] ` <87hamlbk3w.fsf__41794.7558024482$1358063310$gmane$org@Rainer.invalid>
[not found] ` <87hamis0js.fsf@Rainer.invalid>
2013-01-16 9:45 ` Kevin Rodgers
[not found] ` <kd5spq$1hh$1@ger.gmane.org>
2013-01-16 10:06 ` Andreas Schwab
[not found] ` <mvmtxqh5tn0.fsf@hawking.suse.de>
2013-01-16 14:59 ` Kevin Rodgers
2013-01-12 16:29 ` Achim Gratz
2013-01-12 17:01 ` Achim Gratz
2013-01-13 7:46 ` Achim Gratz
2013-01-13 7:52 ` Achim Gratz
2013-01-15 19:34 ` Achim Gratz
2013-01-11 2:45 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hamm8qze.fsf@bzg.ath.cx \
--to=bzg@altern.org \
--cc=10125@debbugs.gnu.org \
--cc=Stromeko@nexgo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).