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