Re: Xemacs needs a real maintainer
On 10 Mar 2004, email@example.com wrote:
> Quoting Uwe Brauer <firstname.lastname@example.org>:
>> On 10 Mar 2004, email@example.com 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 convinient 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.
Besides the pro and cons for emacs and Xemacs by 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.