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

Previous Next

Package: emacs;

Reported by: Jambunathan K <kjambunathan <at> gmail.com>

Date: Thu, 24 Nov 2011 12:15:02 UTC

Severity: normal

Merged with 18443, 18448, 21267

Found in versions 24.0.91, 24.3.93, 25.0.50

Full log


Message #68 received at 10125 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Achim Gratz <Stromeko <at> nexgo.de>
Cc: 10125 <at> debbugs.gnu.org
Subject: Re: bug#10125: RFE: require and load-path-shadowing
Date: Fri, 11 Jan 2013 11:56:07 -0500
>> 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.

IIUC "fork" is not really an option for w32.

>> 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)?

Yes, this subroutine is never directly called from C, so placing an
advice should work just fine.

> 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.

AFAICT the only part of `require' which can't be written in Elisp right
now is the part that handles Vautoload_queue because that variable is
not exposed to Elisp (IIRC this variable is used to undo the effects of
a partially loaded file when the load bumps into an error midway
through; FWIW I'm not convinced this feature works reliably nowadays).

>> 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, …)?

We could try that, as well, but it would only work for those packages
that are "properly namespaced" (and there's no way to detect that
AFAIK).
Along the same lines, we could try to use unload-feature.


        Stefan




This bug report was last modified 9 years and 304 days ago.

Previous Next


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