From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Date: Wed, 16 Jan 2008 15:40:01 -0800 Message-ID: <200801162340.m0GNe1WO025295@sallyv1.ics.uci.edu> References: <20080116001356.GA3081@muc.de> <200801160547.m0G5laV0007175@sallyv1.ics.uci.edu> <20080116213128.GC2171@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1200527023 3412 80.91.229.12 (16 Jan 2008 23:43:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Jan 2008 23:43:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 17 00:43:52 2008 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 1JFHvA-0005UI-3O for ged-emacs-devel@m.gmane.org; Thu, 17 Jan 2008 00:43:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JFHul-00005j-Gm for ged-emacs-devel@m.gmane.org; Wed, 16 Jan 2008 18:43:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JFHuH-0008F8-9F for emacs-devel@gnu.org; Wed, 16 Jan 2008 18:42:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JFHuG-0008Eg-N3 for emacs-devel@gnu.org; Wed, 16 Jan 2008 18:42:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JFHuG-0008ER-CL for emacs-devel@gnu.org; Wed, 16 Jan 2008 18:42:52 -0500 Original-Received: from sallyv1.ics.uci.edu ([128.195.1.109]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JFHuF-000099-Vk for emacs-devel@gnu.org; Wed, 16 Jan 2008 18:42:52 -0500 X-ICS-MailScanner-Watermark: 1201131602.20371@3Fsw1Q3ybNdCFjdBZ/2i2g Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by sallyv1.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id m0GNe1WO025295; Wed, 16 Jan 2008 15:40:01 -0800 (PST) In-Reply-To: <20080116213128.GC2171@muc.de> (Alan Mackenzie's message of "Wed, 16 Jan 2008 21:31:28 +0000") Original-Lines: 77 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) 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:87000 Archived-At: Hi Alan, Alan Mackenzie writes: > > 21.1 was released in October 2001. > > Is the number of people that do not upgrade to emacs-21, but still want > > to use the latest cc-mode significant enough to be worth the trouble? > > Upgrading an unfamiliar piece of software is a nightmare of fear, > uncertainty and doubt. (And Emacs is "unfamiliar" to nearly all its > users in this context.) Will the new version of the software work? More > to the point how much work will it take to get it to work, iron out the > niggly little differences, and so on? The same argument applies to installing a new version of cc-mode too, doesn't it? > I think there will be a lot of Emacs users still on old versions, though > they make very little noise. I don't think giving them compatibility > headaches is the best way of persuading them to upgrade. > > However, this is just my personal opinion. ;-) Well, you are the maintainer, so your opinion matters. > > It's obviously your choice, but is it worth it to still support > > emacs-20? > > Yes, I think so, given how little effort that actually takes. If nothing changes, not much effort is required. If only more recent versions of emacs/XEmacs are supported, then a lot of cruft can go away. A cursory look over the code say that cc-bytecomp-defvar, cc-bytecomp-fboundp and maybe cc-bytecomp-defun can probably go. Compare the bytecode for this: (defmacro c-put-overlay (from to property value) ;; Put an overlay/extent covering the given range in the current ;; buffer. It's currently undefined whether it's front/end sticky ;; or not. The overlay/extent object is returned. (if (cc-bytecomp-fboundp 'make-overlay) ;; Emacs. `(let ((ol (make-overlay ,from ,to))) (overlay-put ol ,property ,value) ol) ;; XEmacs. `(let ((ext (make-extent ,from ,to))) (set-extent-property ext ,property ,value) ext))) With this: (defmacro c-put-overlay (from to property value) ;; Put an overlay/extent covering the given range in the current ;; buffer. It's currently undefined whether it's front/end sticky ;; or not. The overlay/extent object is returned. (if (featurep 'emacs) ;; Emacs. `(let ((ol (make-overlay ,from ,to))) (overlay-put ol ,property ,value) ol) ;; XEmacs. `(let ((ext (make-extent ,from ,to))) (set-extent-property ext ,property ,value) ext))) Not sure if this would make a difference from the performance point of view (it might for c-point for example), but reducing the amount of cc-elisp in favor of elisp seems like a good idea. Just my 2 cents. --dan