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

Previous Next

Full log

Message #74 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 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

Previous Next

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