From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Martin Stjernholm Newsgroups: gmane.emacs.devel Subject: Re: cc-vars.el Date: 18 Nov 2002 23:15:06 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5bbs4m8qz9.fsf@lister.roxen.com> References: <200211180057.JAA24537@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037658654 22304 80.91.224.249 (18 Nov 2002 22:30:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 18 Nov 2002 22:30:54 +0000 (UTC) Cc: Kenichi Handa , rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18DuPP-0005mR-00 for ; Mon, 18 Nov 2002 23:30:23 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18DuRp-0000qZ-00 for ; Mon, 18 Nov 2002 23:32:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18DuNL-0005g2-00; Mon, 18 Nov 2002 17:28:15 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18DuBe-0001g1-00 for emacs-devel@gnu.org; Mon, 18 Nov 2002 17:16:10 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18DuAj-0001RF-00 for emacs-devel@gnu.org; Mon, 18 Nov 2002 17:15:20 -0500 Original-Received: from godzilla.roxen.com ([194.52.182.190] helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 18DuAh-0001Oq-00; Mon, 18 Nov 2002 17:15:11 -0500 Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id B72B499BD; Mon, 18 Nov 2002 23:15:06 +0100 (MET) Original-To: Dave Love In-Reply-To: Original-Lines: 97 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9531 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9531 Dave Love wrote: > /.../ There are typically still some compilation warnings if you do > portability stuff cleanly, but they're not usually excessive. I consider anything more than two warnings all-in-all to be too excessive. After that it's too easy to get accustomed to them and stop looking carefully enough. > I see a comment in cc-bytecomp implying that compilation is supposed > to produce byte code that's portable between Emacs and XEmacs, but > that's a lost cause. True, but it's more valid within different versions of the same branch, e.g. between Emacs 20 and 21, and even more so between minor versions. I had at one point a simple macro system that tested all this at compile time and made completely tailored byte code, and I got a complaint from a user then. I don't remember between what exact versions he tried to port it, but a single complaint isn't much of test data anyway. From it I can only draw the conclusion that the problem exists, not at all how big or small it is. The only way to avoid compiler warnings cleanly (in some sense) is to do the tests with macros at compile time, but that is apparently not a good solution. Thus, the only resort is to make these kludgy symbol and variable bindings. > /.../ Changes to the compiler would help, e.g. to avoid warnings > from > > (unless (fboundp 'fred) > (define fred ...)) It's possible to do something like this without any compiler warnings at all; that's essentially what cc-bytecomp-defun does (and now it hopefully does it correctly too). The problem is not there but rather that it's necessary to actually bind the symbols to get rid of the warnings since there is no other way to hook into the compiler to control them. > A change for that I once suggested greatly reduced the noise and I > don't think it's a big issue to re-write a few things to forms such a > compiler check would be documented to recognize. Don't you rather mean code like this? (if (fboundp 'fred) (fred ...)) It'd be cool if the compiler did enough flow analysis to cope with that, but it might be hard to get it to work well, and if it doesn't work well then I'd prefer to have the possibility to control the warnings explicitly with some pragma-like system. It's really the lack of such a system in the byte compiler that is the problem here. An interesting angle is if something like the following can be used (although I'd consider this too a workaround rather than a solution): (if (boundp 'fido) (symbol-value 'fido)) (if (fboundp 'fred) (funcall 'fred ...)) Someone with insight in the inner workings of the compiler can perhaps advice on how effectively it manages to optimize such things. > I also think it's unwise to try to support ancient versions of > (X)Emacs. That just makes life difficult and takes resources that > could be put into improvements for current versions, especially taking > advantage of new features. That is a valid point to some extent, but it's a choice I prefer to make myself when it comes to my own "upstream" development CC Mode. I approach it this way: If there's some _specific_ feature in newer emacsen that would give a real benefit, and if I think it's too hard to implement compatibility kludges for it, then and only then do I scrap compatibility. (Thus I don't consider an argument that a kludge just looks big and ugly as a valid reason for dropping it.) Anyway, this is besides the point regarding cc-bytecomp, since that one is necessary to keep it working and compiling without warnings on both Emacs and XEmacs. It's actually the support for both flavors that is responsible for approximately 90% of all the time I spend on compatibility kludges. It also means I can't use a new feature until it's so old that it exist in the other flavor, in at least an approximately similar form. (Such a feature is the syntax-table text property, which I intend to make greater use of and which will be the specific reason that CC Mode soon will ditch support for Emacs 19 and XEmacs 19 and 20.) As for the distribution in Emacs I don't really have any objections if someone decides to rip out all the compatibility code, except for one thing: The ripping-out itself is a possible source of errors, and I wouldn't like to have to spend time on hunting down bugs due to that which gets reported to me.