GNU bug report logs - #10125
24.0.91; package.el (org): Macros in tar packages & order of byte compilation

Previous Next

Full log

View this message in rfc822 format

From: Achim Gratz <Stromeko <at> nexgo.de>
To: 10125 <at> debbugs.gnu.org
Subject: bug#10125: RFE: require and load-path-shadowing
Date: Fri, 11 Jan 2013 17:06:53 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.