From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Post-22.1 development? Date: Mon, 4 Jun 2007 10:31:02 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1180978411 9500 80.91.229.12 (4 Jun 2007 17:33:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 4 Jun 2007 17:33:31 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 04 19:33:30 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HvGQr-0005Wh-LB for ged-emacs-devel@m.gmane.org; Mon, 04 Jun 2007 19:33:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HvGQr-00041y-4P for ged-emacs-devel@m.gmane.org; Mon, 04 Jun 2007 13:33:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HvGQm-0003wV-M9 for emacs-devel@gnu.org; Mon, 04 Jun 2007 13:33:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HvGQk-0003n1-7F for emacs-devel@gnu.org; Mon, 04 Jun 2007 13:33:23 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HvGQj-0003mj-UN for emacs-devel@gnu.org; Mon, 04 Jun 2007 13:33:21 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HvGQj-0006Q0-Fo for emacs-devel@gnu.org; Mon, 04 Jun 2007 13:33:21 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l54HXIhE014535 for ; Mon, 4 Jun 2007 12:33:18 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l54FQpVt007621 for ; Mon, 4 Jun 2007 11:33:18 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-81-137.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2820466611180978279; Mon, 04 Jun 2007 10:31:19 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:72217 Archived-At: > In a recent email, Stefan suggested that we should not restrict 22.x > development to bugfixes, but also include new features if the new > features are not too invasive. Do people agree with this approach? > > We can put in a limited set of new features, but only if they > are really important as well as safe. > > As for the trunk, should we begin merging the unicode branch in? > > Let's wait a couple of months. I think it will be easier to move some > changes selectively to the Emacs 22 branch if we have not included > unicode-2 in the trunk. As of now, any change in the trunk would work > in the branch. After unicode-2 is installed, many changes will be > done differently, and they won't work unchanged in the Emacs 22 branch. IIUC, this means that any new features to be added to Emacs, beyond those deemed "really important as well as safe", will be added to Emacs + unicode-2. And that will be after "a couple of months" (which really means...?) plus the time it takes to merge the unicode-2 branch and test it after merging. This means that any libraries or other features we might want to add (beyond those "really important") will need to work with unicode-2 Emacs. I know already that some of my own code, which works perfectly well with Emacs 22, will not work as is with unicode-2 Emacs. For example, my code for zooming frames (default font) breaks. Unicode will, I suspect, change a lot of things, making it more difficult to integrate some new features. However, I do understand that there would also be problems the other way around: if we first integrated, before unicode-2, various libraries that people have not mentioned during the last few "feature-freeze" years, then integrating unicode-2 would itself be harder. I guess that's the way it is, but I thought I'd point this out. I agree that it is probably better to try to make new features work with unicode-2 than the other way around. Better to hold up some minor improvements than a major improvement. It really is a shame that the release cycle is so long. Because of the "feature freeze", I (and I assume others too) have been waiting for years, literally, to bring up some possible features for consideration. Emacs is definitely a cathedral to which generations of builders contribute collectively. Perhaps a distant descendent will finally merge a "new" feature conceived centuries earlier... ;-) A historical viewpoint and a sense of humor definitely help temper impatience. The good news is that a long waiting line means that Emacs development is active - the doctor is just busy with other patients, not on vacation.