From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Wedler, Christoph" Newsgroups: gmane.emacs.devel Subject: RE: [Suggestion] New function `emacs-version>=' Date: Mon, 5 May 2003 14:52:25 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <67B8CED503F3D511BB9F0008C75DAD66054855CB@dewdfx17> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: main.gmane.org 1052139916 3440 80.91.224.249 (5 May 2003 13:05:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 5 May 2003 13:05:16 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 05 15:05:09 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 19CfVV-0000I8-00 for ; Mon, 05 May 2003 14:55:49 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19CfYW-0000f6-00 for ; Mon, 05 May 2003 14:58:56 +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 19CfU7-0006c8-00 for emacs-devel@quimby.gnus.org; Mon, 05 May 2003 08:54:23 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19CfT4-0006At-00 for emacs-devel@gnu.org; Mon, 05 May 2003 08:53:18 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19CfSf-0005Nt-00 for emacs-devel@gnu.org; Mon, 05 May 2003 08:52:56 -0400 Original-Received: from smtpde02.sap-ag.de ([155.56.68.170]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19CfSJ-0004Bf-00; Mon, 05 May 2003 08:52:31 -0400 Original-Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id OAA17097; Mon, 5 May 2003 14:52:46 +0200 (MESZ) Original-To: "'rms@gnu.org'" X-Mailer: Internet Mail Service (5.5.2656.59) X-SAP: out X-SAP: out 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:13688 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13688 Richard Stallman wrote: > It occurs to me that it might be useful to extend > and < to compare > lists of numbers, and also conses of two numbers. emacs-version>= > could trivially use that. A "lexical-order extension" of < and > looks like a good idea. A remaining question: - will `emacs-version>=' be defined based on that? or - is `emacs-version>=' considered too simple with this extension (a constant `emacs-patch-level' would be useful then) To the discussion whether/when `emacs-version>=' should be used: Of couse, as I said before, if a feature/fix A could be tested *directly*, one should use that test, not some version or Emacs-vs-XEmacs test. E.g., - (featurep 'some-feature) - (fbound 'some-function) ; I only mentioned this in my prev mail - (boundp 'some-var) The point is, as Stefan mentioned, that quite often, feature/fix A cannot be tested directly (that's why I always included "fix" to make it clearer). I used to think like many here that version or Emacs-vs-XEmacs tests should be avoided whenever possible, but I don't think anymore that this is right. One should not use tests like the ones above indirectly: - test for the `display' property: CORRECT: (emacs-version>= X Y) WRONG: (fboundp 'some-function-introduced-with-X.Y) - test for some bug fix CORRECT: (emacs-version>= X Y) WRONG: (fboundp 'some-function-introduced-with-X.Y) - test for "how things are done" in Emacs or XEmacs CORRECT: (featurep 'xemacs) WRONG: (fboundp 'some-function-only-defined-in-xemacs) Reason: a future Emacs might define the function as a compatiblitiy function, but you still want to do it the Emacs' way Juanma Barranquero wrote: > And, as a last resort, you can often do something like > (unless (ignore-errors XXXX) > YYYY) similar in : > When that is not possible, use > (condition-case nil > (emacs-code) > (error (xemacs-code))) Well, I don't think this is right (in general[1]). (Ehud also gave an example where this can fail to work.) For example, XEmacs' `directory-files' has an optional 5th arg FILES-ONLY. If I test (condition-case nil (directory-files some-dir nil nil nil t) (error (..EMACS-CODE...))) 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 (if (featurep 'xemacs) (directory-files some-dir nil nil nil t) (..EMACS-CODE...)) Juanma Barranquero wrote: > [...] But most features are not isolated, there are related > variables, functions [...another mail...] Wouldn't, in that case, be > enough to test for just *one* of these multiple features? 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 (boundp 'enable-multibyte-characters) 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?). In other words, the tests shouldn't depend on whether there are some compatiblitiy functions or variables. Juanma Barranquero wrote: > Whether the feature is available in version X.Y is not that > clear-cut, specially if you're testing for a feature that appears in > a branch before being installed in the trunk (or even as a temporary > measure, while another, better fix is installed on the trunk). I must say I don't really care too much if I miss a fix in some temporary development branch. - Christoph [1] Yes, I read Juanmas "often", but I didn't argue against all `fboundp' tests either...