nfreimann <[EMAIL PROTECTED]> writes: > --- August <[EMAIL PROTECTED]> schrieb: > >> With "the standard Emacs release" I mean the non-CVS >> version. Will this >> GUI support make it to the next release? > > cvs emacs offers gkt and advanced windows support > since more than an year. Therefore I wonder that the > new 21.4 does not support gtk.
21.4 has for a long time been touted as the next great release to come, with lots of features and so on. Unfortunately, a serious security flaw necessitated a quite unplanned release in between, preempting the version number 21.4. 21.4 is identical to 21.3, with the single security fix applied. In order not to confuse people, should something like this be required again, the next _feature_ release will be called 22.1. So 22.1 will definitely support Windows _with_ tooltips and toolbars and images, and Carbon in the same manner, and GTK. It is not expected that we will see a release 21.5, but should it surprise us in the manner that 21.4 did, it will very likely contain nothing like GTK or full Carbon or Windows support. > Clearly spoken, emacs without gkt and advanced windows support is > outdated. Its looks anachronistic and behaves crippled in linux as > well as in windows. > > There is a excellent windows binary cvs emacs distribution available > at http://nqmacs.sourceforge.net/. Its the best windows emacs > ever. Why not supporting a binary cvs gtk2-emacs for linux at > ftp.gnu or sourceforge.net? Whats the problem with that? "Supporting a CVS" Emacs is an oxymoron. The CVS Emacs is notable for having typically dozens of changes applied daily. Some of them are extensive, leading to instability. Handpicking a reasonable stable variant, removing debug code, probably applying some fixes while leaving out others, is work for a QA department. It would require at least one person working concentrated on just keeping up the quality of such a "supported binary". This sort of QA work does not require as much qualification as the actual development does, but it still requires quite a bit of work. The resulting consistent quality would probably at this stage of development not be considerable above the average that we have now, but would basically just have the single advantage of being consistent: lower chance to catch a lemon that you would want to fix at most a few days later. This sort of job could well be done by an average programmer: no special Emacs programmer would be required for that. The need does not seem as large as to cause an organized effort, though. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Help-gnu-emacs mailing list Help-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
