[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Suggestion] New function `emacs-version>='
From: |
Wedler, Christoph |
Subject: |
RE: [Suggestion] New function `emacs-version>=' |
Date: |
Mon, 5 May 2003 14:52:25 +0200 |
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 <http://www.dina.dk/~abraham/religion/crossemacs.html>:
> 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...
- Re: New function `emacs-version>=', (continued)
- Re: New function `emacs-version>=', Richard Stallman, 2003/05/04
- Re: New function `emacs-version>=', Reiner Steib, 2003/05/03
- Re: New function `emacs-version>=', Stefan Monnier, 2003/05/03
- sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>='), Reiner Steib, 2003/05/05
- Re: sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>='), Kenichi Handa, 2003/05/06
Re: [Suggestion] New function `emacs-version>=', Thien-Thi Nguyen, 2003/05/02
Re: [Suggestion] New function `emacs-version>=', Richard Stallman, 2003/05/04
Re: [Suggestion] New function `emacs-version>=', Istvan Marko, 2003/05/06
RE: [Suggestion] New function `emacs-version>=',
Wedler, Christoph <=
RE: [Suggestion] New function `emacs-version>=', Wedler, Christoph, 2003/05/06
RE: [Suggestion] New function `emacs-version>=', Wedler, Christoph, 2003/05/07