Re: future of quail
Julian Bradfield writes:
It would be much more of a nuisance for me. If I wanted to include a
single piece of GPL3 code, I would have to do all the work on the 21.4
codebase that Stephen and co. do on the 21.5 codebase in order to release
my fork (which I do intend to do once it has all the features I
consider essential). And then SXEmacs would be unable to use it if
they wanted to.
Erm, SXEmacs has been GPLv3 for more than three years now. AFAIK,
they didn't bother to do the work that we've done on checking
authorship and permissions; they just changed the notices and assumed
that nobody would care. That's very probably true, except that we're
on the FSF's radar in a way that SXEmacs is not (yet, anyway) so I
didn't want to risk it.
It doesn't appear to me that Emacs is going anywhere fast,
either.
They are mature pieces of software.
No, I don't think any of the Emacsen are currently going anywhere
fast. TeXmacs is an interesting variant, but TeX is also too *cough*
"mature" to be easily mated to Emacs in a flexible, programmable way.
I have some other possibilities in mind (Emacs with native access to
enhanced[1] git repos for one; an AJAX/SVG redisplay for another), but
they're years from implementation if I have to do them. :-)
Footnotes:
[1] Sub-file blobs, eg, what Emacs modes think of as defuns. Then
consider the possibilities for refactoring.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta