Re: Elpa packages and macro dependencies.

[Achim Gratz <Stromeko@nexgo.de>]

Stefan Monnier writes:
>> Clever advises or aliases the user has set up that change what gets
>> compiled.  Another possibility are manually loaded packages that
>> misguide feature checks at compile time.  The old cl macros were a rich
>> source of potential problems if you weren't careful, but the advent of
>> cl-lib has made things much cleaner.
>
> I can think of many different hypothetical ways it can fail, indeed, but
> I'm wondering about actual cases.

Let's just say that a certain class of mysterious and usually
non-reproducible failures have stopped to be reported ever since I've
made sure that Org gets compiled and tested in a fresh and clean Emacs
instance.  We get such reports now and then from people who are trying
to use ELPA and our usual recommendation is to install the package from
"emacs -Q" which is a bit painful for someone who was hoping to have an
easier install method.

Now, Org probably wasn't what Tom had in mind when writing package.el,
but if more of Emacs' built-in packages get moved to ELPA (I don't know
if that is the plan), then there will be quite a few more such packages.

I think it's worth keeping the current simplicity of package.el for
those packages that don't need anything more complicated, so one thing
that comes to mind is to move these things to the package, maybe in the
form of callbacks.  If you look at org-reload it could very well be
factored out into a function that takes a few lists or regexes.  The
same should be possible for the advice to require.


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