From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: [Suggestion] New function `emacs-version>=' Date: Mon, 05 May 2003 15:20:52 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20030505150352.2D00.JMBARRANQUERO@laley.wke.es> References: <67B8CED503F3D511BB9F0008C75DAD66054855CB@dewdfx17> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1052141122 10253 80.91.224.249 (5 May 2003 13:25:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 5 May 2003 13:25:22 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 05 15:25:15 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Cfv2-0002O5-00 for ; Mon, 05 May 2003 15:22:12 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19Cfy3-0000xE-00 for ; Mon, 05 May 2003 15:25:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19CftU-00042U-00 for emacs-devel@quimby.gnus.org; Mon, 05 May 2003 09:20:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19Cfsr-000403-00 for emacs-devel@gnu.org; Mon, 05 May 2003 09:19:57 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19Cfsp-0003x4-00 for emacs-devel@gnu.org; Mon, 05 May 2003 09:19:56 -0400 Original-Received: from laley-actualidad.es ([195.53.61.17] helo=haya.laley.net) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19Cfsp-0003vb-00 for emacs-devel@gnu.org; Mon, 05 May 2003 09:19:55 -0400 Original-Received: from idefix.laley.net (correo.wke.es [172.17.220.16]) by haya.laley.net (8.9.3/8.9.3) with ESMTP id PAA17219; Mon, 5 May 2003 15:17:48 +0200 Original-Received: from [172.17.221.17] (jelahue.wk.org [172.17.221.17]) by Version 5.5.2655.55) id KB0ZBW0W; Mon, 5 May 2003 15:20:49 +0200 Original-To: "Wedler, Christoph" , emacs-devel@gnu.org In-Reply-To: <67B8CED503F3D511BB9F0008C75DAD66054855CB@dewdfx17> X-Mailer: Becky! ver. 2.05.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13690 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13690 > One should not use tests like the ones above indirectly: >=20 > - test for the `display' property: >=20 > CORRECT: (emacs-version>=3D X Y) > WRONG: (fboundp 'some-function-introduced-with-X.Y) >=20 > - test for some bug fix >=20 > CORRECT: (emacs-version>=3D X Y) > WRONG: (fboundp 'some-function-introduced-with-X.Y) This may surprise you, but I agree that the tests you've labeled WRONG are, in fact, wrong :-) What I'm not so sure about is that emacs-version>=3D is the CORRECT test=20 (I agree with the "featurep 'xemacs" test too). OTOH, I don't have a better answer. Any one we include is going to be of little help with pre-21.4 Emacsen. Perhaps we need a `fixes' list, =E0 la `features', where people would put info about difficult-to-test changes on interfaces (only half joking here). > For example, XEmacs' `directory-files' has an optional 5th arg > FILES-ONLY. If I test >=20 > (condition-case nil > (directory-files some-dir nil nil nil t) > (error (..EMACS-CODE...))) >=20 > this would fail if Emacs introduces a 5th arg with a different > semantics. In other words, such a test is only correct if you know that > Emacs will define a 5th arg with the same semantics as XEmacs (or will > never define a 5th arg, but you'll never know that). If this is not the > case, it is better to use >=20 > (if (featurep 'xemacs) > (directory-files some-dir nil nil nil t) > (..EMACS-CODE...)) I agree wholeheartedly, and in fact I don't remember arguing against that kind of test. Anything that can be checked with featurep or other existence predicates probably should be. My `ignore-errors' example was for a change between Emacs versions (I know too well, as I was the one who introduced the MODIFIER argument to `windmove-default-keybindings'). > This is also very dangerous. E.g., if you want to test whether your > Emacs distinguishes between buffer with unibyte and some with multi-byte > chars, you might want to test >=20 > (boundp 'enable-multibyte-characters) >=20 > Unfortunately, this doesn't work since XEmacs defines this variable as a > compatiblitiy variable (but it doesn't define `set-buffer-multibyte', > but who knows whether XEmacs will define this function as a > compatiblitiy function in the future?). Ok, but something of this size should be marked as a feature somehow. > I must say I don't really care too much if I miss a fix in some > temporary development branch. Sure, but I was talking specifically of cases where an Emacs version is released with a fix/feature that afterwards is discarded because the trunk release contains a better fix/feature (I wouldn't be surprised if that happens for mule-related things). And don't forget that 21.2, a bugfix-only release, has been around for a year, so "temporary" is a relative term. > [1] Yes, I read Juanmas "often", but I didn't argue against all > `fboundp' tests either... Fair enough ;-) All in all, if people feels that emacs-version>=3D is going to ease life fo= r elisp developers, who am I to oppose... :-) Juanma P.S.: Sorry for excesive quoting in this message. I didn't want to take out too much context.