future of quail

Stephen J. Turnbull stephen at xemacs.org
Tue Feb 15 14:56:57 EST 2011


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.




More information about the XEmacs-Beta mailing list