Re: Xemacs needs a real maintainer
On 10 Mar 2004, firstname.lastname@example.org wrote:
> Quoting Uwe Brauer <email@example.com>:
>> On 10 Mar 2004, firstname.lastname@example.org wrote:
>>>> I forget to add one important thing of course, the Xemacs package
>>>> system which allows on the fly actualization. Emacs has nothing
>>> According to what I read, it is not a missing feature, it is an
>>> unwanted feature. I'm personaly happy with packages provided as
>>> debian packages, so i don't need to grab the big bunch of packages
>>> I don't use (emacs21-support or alike).
>> Just a moment,
> Warning: I don't want this debate to turn into another war, that has
> no place among emacsen users.
Right I agree.
> Except that you cannot keep track of packages you installed throught
> dpkg -l. Furthermore, I checked myself available XEmacs packages
you mean third party packages can not be handled by PUI? Very true
*one* of the missing features of the Xemacs package system. The
problem has been addressed however the lack of manpower so far has
prevented any progress.
The *second* missing feature IMHO is the lack of something like
_alien_ a utility which would allow you to convert regular vanilla
lisp packages into the Xemacs pkg format.
> (in the CVS package CVS), some of them are outdated, mostly because:
> - noone cares for maintaining them (ada mode, ibuffer mode, ...) -
> some of them come from a sync with the GNU tree and require more
> tweek, which requires manpower)
> I'm not saying this package system is bad, but that it is not always
This is true, I myself volunteered to maintain 2 pkg, since I found
them very outdated. Again my point is for a average user it is much
more convenient to use the Xemacs package system to upgrade a lisp
package than it is for the average GNU emacs user.
> This is not entirely true. XEmacs packages are not directly grabbed
> from upstream places. They require some work for being integrated in
> the package tree at xemacs.org.
I am not sure I understand what you mean. Do you mean to turn a given
lisp package into the Xemacs package format. This is a non trival task
I agree, see above. On the other hand, even given that debian has
alien an official package usually would not be generated using such a
converter. But then we come to the point turning a program into a some
kind of package system is non trivial, not for debian not for xemacs.
Besides the pro and cons for emacs and Xemacs my point was that debian
could _save some work_ by taking the Xemacs pkg and not re-write them as
debian packages, like the x-symbol-debian package which is quite
outdated. And BTW what you said about the Xemacs package system of
course applies for the debian system: some debian system are out of
syn with the original package, tex4ht is an example which occurs to
me, there might be more.