help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: An alternative to a monolithic ~/.emacs init file


From: rustom
Subject: Re: An alternative to a monolithic ~/.emacs init file
Date: Wed, 14 Nov 2007 03:52:43 -0000
User-agent: G2/1.0

Thanks Tim for the pointers.



On Nov 13, 2:26 pm, Tim X <t...@nospam.dev.null> wrote:
> Ah, yep, your running into one of the issues with using a distro packaging
> system. Packages like ecb depend on a stand alone speedbar package (as do
> the others you listed, but don't know about speedbar now being packaged in
> emacs itself. I'm not sure if you could use the force option to apt to
> install ecb or not. The other issue may also be that I think the bundled
> speedbar version in emacs 22 is older than the version in the stand alone
> package (at least, this was the case some time back before emacs 22 was
> released.)

This is clearly a bigger problem than people are accepting: viz that
there are large systems of packages which are tolerably consistent in
themselves but dont talk nice to each other -- think of
apt <-> emacs
apt <-> ruby/python
eclipse <-> python
apt <-> webmin

I believe that a decent response to this issue will need:
1. A carefully thought-out standardized data oriented way (not XML
please!) for managing package repos
2. An event driven engine maybe along the lines of upstart see
https://wiki.ubuntu.com/ReplacementInit
3. built on an SOA backbone.  Yeah I know that programmers are likely
to think of this as unsubstantiated hype but when we do apt-get
install foo we are using an SOA



reply via email to

[Prev in Thread] Current Thread [Next in Thread]