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

[Juanma Barranquero <jmbarranquero@laley.wke.es>]

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

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>= is the CORRECT test 
(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, à 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
> 
>    (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...))

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
> 
>    (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?).

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>= is going to ease life for
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.