From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.help Subject: Re: Compiling Emacs with GTK Date: Sat, 26 Feb 2005 02:12:55 +0100 Organization: Organization?!? Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109380323 29177 80.91.229.2 (26 Feb 2005 01:12:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 26 Feb 2005 01:12:03 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Feb 26 02:12:03 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D4qUu-0001zJ-QQ for geh-help-gnu-emacs@m.gmane.org; Sat, 26 Feb 2005 02:11:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4qmm-00012I-0g for geh-help-gnu-emacs@m.gmane.org; Fri, 25 Feb 2005 20:30:24 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!news-FFM2.ecrc.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 57 Original-X-Trace: individual.net 9zq/bOzQ6yVHNXp3rx/zjwnzakf2zIXzyTRcqf/T1vkkOdg+Il X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:BAJ8++WvS6aBzjLTet5lBpDDjxg= Original-Xref: shelby.stanford.edu gnu.emacs.help:128816 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org X-MailScanner-To: geh-help-gnu-emacs@m.gmane.org Xref: main.gmane.org gmane.emacs.help:24356 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:24356 nfreimann writes: > --- August 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