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


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Achim Gratz <Stromeko <at> nexgo.de>
Cc: 10125 <at> debbugs.gnu.org
Subject: bug#10125: RFE: require and load-path-shadowing
Date: Fri, 11 Jan 2013 17:52:33 -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.
> For the intended application spawn should work as well?

Could be: depends on the precise semantics of spawn, which I don't know.

>> Along the same lines, we could try to use unload-feature.
> I thought this was potentially dangerous, but reading the docstring
> again maybe not.  Let me try that as well.

It's fundamentally tricky just in the same way as your proposed
"namespace cleanup": if you undefine a function that's still registered
on some hook, process filter, ... you may get subsequent errors, some of
which may render Emacs completely unusable.
So it's risky to call unload-feature on a random package, but it's not
too hard for a package to make sure it survives unload-feature.
Tho currently, there are some significant shortcomings (IIRC there are
cases where the package's autoloads aren't re-instated, for example).


        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.