Re: That "vision" thang...

Mats Lidell wrote: 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. 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 do. 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? 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 widechar buffers. Andreas Roehler writes: Go right ahead. :-) 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 XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta