emacs-devel
[Top][All Lists]
Advanced

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

Re: RFC: Adding BBDB to Emacs core


From: Phillip Lord
Subject: Re: RFC: Adding BBDB to Emacs core
Date: Sun, 15 Apr 2018 22:20:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux)

Glenn Morris <address@hidden> writes:

>> I'd like BBDB to become the default out-of-the-box local contact
>> management library for GNU Emacs, in particular so that Gnus/EUDC/BBDB
>> work together to provide email completion and snarfing out-of-the-box,
>> without extra configuration or package installation.
>
> If GNU ELPA is a first-class citizen, then all the above can happen
> without adding yet more stuff to the main Emacs repo. (Wistfully
> thinking here yet again of the project to bundle GNU ELPA packages with
> Emacs releases...)

I've part-written two different versions of this, both in git.

They work in different ways; but ultimately, I think we need to decide
what "ELPA as a first-class citizen" actually means.

This version:

http://git.savannah.gnu.org/cgit/emacs.git/log/?h=elparized-core

for example, just pulls out parts of ELPA using git magic, and copies
the files into core. Simple, straight-forward and it works. But,
ultimately, will it make maintaining core more easy? In the end, I think
not, because it is essentially an ad-hoc way of tying together emacs.git
and elpa.git.


This version:

http://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/integrated-elpa

uses package.el during the build process of Emacs, so that ELPA packages
could be added as packages. It requires more work. In the end, my own
feeling is that this is the right way. We could dramatically slim down
core Emacs to be enough to run package.el. The release would then be
"core plus what ever packages we think are important at the time".

This would decrease the complexity of the emacs git. But it might
increase the complexity of the release process, since you'd be dependent
on multiple other packages. I think ELPA and package.el need
to be able to cope with multiple versions of the same package,
supporting different versions of Emacs for this to work.


Phil



reply via email to

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