From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: bug#10125: RFE: require and load-path-shadowing Date: Fri, 11 Jan 2013 17:06:53 +0100 Message-ID: <87wqvjd7qa.fsf@Rainer.invalid> References: <87sj68eogm.fsf@Rainer.invalid> 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]:46457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tth9D-0007wj-4n for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 11:08:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tth99-0001wO-BF for emacs-orgmode@gnu.org; Fri, 11 Jan 2013 11:07:58 -0500 In-Reply-To: <81pqgh90sp.fsf@gmail.com> Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-Message-ID: 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: 10125@debbugs.gnu.org Stefan Monnier writes: > I guess we could fork Emacs early on and keep this second process > around as a "process from which to generate new clean slates". I've been thinking about something like this for a while… if it worked at least as well as starting a new Emacs instance on all platforms, I'd favor this approach. > - outdated .elc file taking precedence over the new .el file can do > the same. Yes, but you get a warning and can already arrange for this (by binding the appropriate variables) to be no problem in practise. See the way org-reload works in current master (of the Org repo). > - bytecompiling a file affects the running session by side-effects such > as requiring packages. If that problem was finally solved that would be very welcome. > I suggested a quick&dirty solution: >> > E.g. we could add to bytecomp.el the ability to force `require' to >> > reload a package if it's not already loaded from the file that >> > locate-library returns. > > I still think it's not a bad option. Would an advice work in this situation (given that require is a primitive)? If yes, I'd like to give it a try over the weekend. If not, I don't really see why require, more specifically the part that checks features needs to be a primitive, so maybe it could be moved partly to elisp. > Of course, we'd still get trouble when the loading is not performed via > `require' but via autoload (maybe we could try and attack this problem > by allowing `autoload' to override an already existing definition, but > that could be delicate). That I'd like to split off from the discussion about require. > I don't see why that would introduce a difficulty. As long as the package is properly namespaced, why not allow for removing all definitions pertaining to that entire namespace (features, autoloads, definitions, …)? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada