Mats Lidell wrote:
> My suggestion for a plan would be this:
> - Release 21.5 as stable (Do as little as possible to get
Requires a release manager, but given a release manager we can do
that. IMHO there's a lot to be done, though. A lot of the attractive
features suck. Eg, Xft's complete confusion in configuring fonts. We
also really ought to consider a massive GNU sync if we want to recover
any of the mindshare that that wiki page indicates we've lost.
> - Go GPLv3 for the next release after that.
I think this is actually the highest priority, as it prevents most
people from doing any GNU syncing (althoug Aidan has demonstrated it's
possible). It's also something that somebody other than Ben Wing can
> - Select a portable windows system to be used on all
> platforms. (So little time to support all so we need to
> focus on one plus we need eye-candification.)
Jamie has suggested "HTML".
This is a rather large amount of work (eg, probably more than one
Google SoC student could handle).
A big technical problem we face there is that they all come with their
own event loops. So much of what makes Emacs nicer than many other
editors is the modelessness, but making that work smoothly depends a
lot on features like C-g actually interrupting Emacs quickly. I don't
know if there are any high-level toolkits that allow you to do this.
Another problem is that many of them only can handle one display at a
time AFAIK. Unacceptable to me personally, I'd have to stop using
XEmacs! I suppose GTK can handle multiple displays by now? But how
about the higher level toolkits like wxWindows? And do they flexibly
allow input from other sources like background subprocesses and TTY
displays and gnuclient?
> - Better, faster, support for parsing to improve font-locking
This is hard. Slowness in extents is at a very low level in the
code. The fastest way to get speed here may actually be to implement
Andreas Roehler writes:
Saw it was already discussed last summer.
Maybe it's time to do it now.
Go right ahead. :-)
As a rewrite of fontifying is a larger project, I
suggest a launchpad account for it.
Er, shouldn't it be a branch off the trunk? So not unless you plan to
take the main repo with it. Eventually you want to merge it, no? Or
does launchpad support Mercurial repos?
XEmacs-Beta mailing list