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

Re: XEmacs, Emacs and elisp

>>>>> "Manoj" == Manoj Srivastava <srivasta@datasync.com> writes:

 Manoj> Hi,
 >>> "Helmut" == Helmut Geyer <Helmut.Geyer@IWR.Uni-Heidelberg.De>
 >>> "Milan" == ilan Zamazal <pdm@blackbird.ics.muni.cz>
 Manoj>  [A good discussion of the problems with supporting multiple
 Manoj> Emacsen on the same box partly elided]

 Manoj> 	  I think I lean towards a total separation of both
 Manoj> emacsen, with two packages for each add-on, one package
 Manoj> catering to the needs of each variant.

 Manoj>   vm-emacs vm-xemacs tm-emacs tm-xemacs

 Manoj> 	and so on, as being the only solution technically feasible
 Manoj> in the long run. It is cleaner, and the only con is disk space
 Manoj> usage (which maybe be the lesser evil compared to what we may
 Manoj> face as the elisp dialects continue to evolve apart).

Here is my opinion on the matter.  Disk space is cheap, and although
it is a little more complicated for elisp package maintainers to deal
with it isn't too bad.

Here is my proposal:

XEmacs distribution remains whole.  No split.
Emacs comes as normal.
  There are a bunch of packages that don't come with emacs
  that will be distributed as emacs only version (vm, etc)
  so there is no problem for these package maintainers to
  deal with.
  These get installed in /usr/lib/emacs/site-lisp

Any packages that do not come with XEmacs will be dealt with
on a package by package basis by their maintainers.  So for
instance calc.  This package actually works dandy with both
versions.  So it can be installed in

Any packages that do not work fine in both be distributed as
two packages (and I'd be happy to take over the XEmacs half
if anyone does not have time to do both).  Emacs package goes
in /usr/lib/emacs/site-lisp.  XEmacs package does in
/usr/lib/xemacs/site-lisp.  Of course I can see there being
occasional disagreements between XEmacs 20 and 19 so there are
also /usr/lib/xemacs/site-lisp-(20|19) directories as well.

This is complex I admit, but it is the cleanest solution IMO.


@James LewisMoss                 | moss@cs.sc.edu | Blessed Be!
@    http://www.cs.sc.edu/~moss  | dres@scsn.net  | Linux is cool!
@"Argue for your limitations and sure enough, they're yours." Bach

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com

Reply to: