RE: [Suggestion] New function `emacs-version>='

["Wedler, Christoph" <christoph.wedler@sap.com>]

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...