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

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

[Wedler, Christoph]

I would like to see the following function defined in Emacs[1]:

(defun emacs-version>= (major &optional minor patch)
  "Return true if the Emacs version is >= to the given version.
The version is provided by the required argument MAJOR, and the optional
arguments MINOR and PATCH.  Only the non-nil arguments are used in the
test."
  (cond ((> emacs-major-version major))
	((< emacs-major-version major) nil)
	((null minor))
	((> emacs-minor-version minor))
	((< emacs-minor-version minor) nil)
	((null patch))
	((string-match "^[0-9]+\\.[0-9]+\\.\\([0-9]+\\)" emacs-version)
	 (>= (string-to-int (match-string 1 emacs-version)) patch)))))

(Of course, a constant `emacs-patch-version' could be defined, as well.
The function above would be changed to use it.)

Specific features or bug fixes are only available in newer Emacsen and
packages must be able to cope with it.

A test like `fboundp' is only the right test iff the new feature to test
for availibility is a function, it is not the right test for

 - I need to check the availibility for feature/fix A
 - feature/fix A is provided with Emacs-X.Y
 - function F is new with Emacs-X.Y
 - therefore I test with (fboundp 'F)

The right test is

 - I need to check the availibility for feature/fix A
 - feature/fix A is provided with Emacs-X.Y
 - therefore I test with (emacs-version>= X Y)

Like it or not, a test like `emacs-version>=' would be useful for many
packages, thus a corresponding function would be useful to define in
Emacs.

- Christoph

[1] This function is already defined in XEmacs.

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

[Thien-Thi Nguyen]

"Wedler, Christoph" <christoph.wedler@sap.com> writes:

    - I need to check the availibility for feature/fix A
    - feature/fix A is provided with Emacs-X.Y
    - therefore I test with (emacs-version>= X Y)

for features and fixes it's best to be direct.  if `fboundp' is not
direct enough, use something that is.  (using a version number is
completely indirect.)

a test using the version number is made obsolete by any number of
scenarios, one of which is called parallel changes:

	version 1:
		A => X
		B => Y
		A*B => Z

	version 2:
		A => XX
		B => Y
		A*B => Z

	version 3:
		A => XXX
		B => YYYY
		A*B => Z

here, A and B are pieces of code, A*B is their interaction, and X, Y and
Z are some user- or programmer-visible behaviors.

Z is what you want (as in ZZZZZ as in a nice nap on a sunny day :-).  if
you check Z directly, you notice no change and life is good.  if you
check Z indirectly by checking A or B or A*B (or X or Y or combinations
thereof), you have many more ways to screw up and incorrectly conclude
the wrong thing.

apologies if this is not completely clear, i'm feeling sleepy for some
reason....  there are other scenarios, too, that perhaps someone can
while away a few minutes pointing out.  anyway, having gone through the
pain of conditionalizing based on version numbers for my own code (and
then arriving at understanding much later), i recommend against the
practice now, seductive as it may appear on the surface.

thi

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

[Richard Stallman]

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.

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

[Wedler, Christoph]

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: [Suggestion] New function `emacs-version>='

[Juanma Barranquero]

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

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

[Richard Stallman]

    A "lexical-order extension" of < and > looks like a good idea.  A
    remaining question:

     - will `emacs-version>=' be defined based on that?

If anyone wants it, I guess so.

    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)

People have also shown various ways of testing the behavior of a function
to see if a bug has been fixed.  I think those are good approaches.

But I agree with you that testing indirectly related
criteria--criteria that are only indirect ways of testing for a
certain version--is not wise, and that it is better to test the
version number openly than to for the version indirectly.

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

[Luc Teirlinck]

Christoph Wedler wrote:

   (a constant `emacs-patch-level' would be useful then)

What would that constant represent?  From the code of emacs-version>=
you proposed, it would seem that it would be say the "2" in
emacs-21.3.2, representing the second instance of 21.3 the user built
in the given directory, or the "50", in emacs-21.3.50.43 (or
whatever).  If so, patch-level 50 for emacs-21.3 could represent the
50th time that a "compulsive Emacs builder" built Emacs-21.3 or it
could represent a snapshot of emacs-21.3.50.  That would not seem to
make a whole lot of sense.  Or how exactly would you define that
constant?

Sincerely,

Luc.

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

[Wedler, Christoph]

Luc Teirlinck wrote:
 > Christoph Wedler wrote:

 >    (a constant `emacs-patch-level' would be useful then)

 > What would that constant represent?

Well, some emacs-minor-minor-version ;-)  I don't know the current Emacs
version numering scheme.

I thought it would be the 3rd number in `emacs-version' because the
Emacs-21.3 pre-releases had a useful numering scheme, i.e., they had
versions 21.2.90, 21.2.91, ...

Since there might be some bug-fix releases of Emacs-21.3 before
Emacs-21.4 is out, I would think it would be useful to have versions
numbers 21.3.0, 21.3.1 etc for them.  How do I distinguish between such
Emacs-21.3 versions now?  Or is the first bug fix of Emacs-21.3 called
Emacs-21.4 (and the second Emacs-21.5)?

I would also have guessed something similar for the Emacs development
version... (e.g., that they start with Emacs-21.3.40 or whatever...)

 > From the code of emacs-version>= you proposed, it would seem that it
 > would be say the "2" in emacs-21.3.2, representing the second
 > instance of 21.3 the user built in the given directory, or the "50",
 > in emacs-21.3.50.43 (or whatever).  If so, patch-level 50 for
 > emacs-21.3 could represent the 50th time that a "compulsive Emacs
 > builder" built Emacs-21.3 or it could represent a snapshot of
 > emacs-21.3.50.

Err, obviously, Emacs has a different the numering scheme...

 > That would not seem to make a whole lot of sense.

Indeed, but it could make sense if adopted to the Emacs version numering
scheme (which might need to be defined).

- Christoph

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

[Luc Teirlinck]

Chris Wedler wrote:

   I thought it would be the 3rd number in `emacs-version' because the
   Emacs-21.3 pre-releases had a useful numering scheme, i.e., they had
   versions 21.2.90, 21.2.91, ...

I do not see why a package developer would want to support old
pre-releases.  It seems to me that pre-releases become obsolete once
the actual version is released.

   Since there might be some bug-fix releases of Emacs-21.3 before
   Emacs-21.4 is out,

I believe that Emacs-21.3 is itself a bug-fix release.

   I would think it would be useful to have versions numbers 21.3.0,
   21.3.1 etc for them.  How do I distinguish between such Emacs-21.3
   versions now?

In as far as I know, there is only one version of Emacs-21.3.  Except
that the user could build several different versions, using different
toolkits or whatever.  These will get different third numbers, but
only the user knows the meaning of that third number.

   Or is the first bug fix of Emacs-21.3 called
   Emacs-21.4 (and the second Emacs-21.5)?

Yes.  Unless there are new-feature releases in between.

   I would also have guessed something similar for the Emacs development
   version... (e.g., that they start with Emacs-21.3.40 or whatever...)

The current CVS is Emacs-21.3.50.  You get a fourth number telling you
how many times you built it.

Essentially, the information you want from `emacs-patch-level' is
already contained in `emacs-minor-version'.  You just wind up with
more minor-versions, since each bug-fix release increments
`emacs-minor-version'.

Sincerely,

Luc.

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

[Istvan Marko]

"Wedler, Christoph" <christoph.wedler@sap.com> writes:

> Like it or not, a test like `emacs-version>=' would be useful for many
> packages, thus a corresponding function would be useful to define in
> Emacs.

How about something like gnus-continuum-version that would return the
version as a floating point number:

(gnus-continuum-version)
5.09002

-- 
	Istvan

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

[Richard Stallman]

We have no need for minor-minor versions.  Whenever we make
a release, we increment at least the minor version number.

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

[Wedler, Christoph]

Richard Stallman:
 > We have no need for minor-minor versions.  Whenever we make
 > a release, we increment at least the minor version number.

OK.  Remaining questions:

 - What's the official way to distinguish Emacs-21.2 from the Emacs-21.3
   pre-releases (Emacs-21.2.9x)?

 - What's the official way to distinguish Emacs-21.3 from the current
   development versions (Emacs-21.3.50.X)?

- Christoph

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

[Luc Teirlinck]

Christoph Wedler wrote:

   OK.  Remaining questions:

    - What's the official way to distinguish Emacs-21.2 from the Emacs-21.3
      pre-releases (Emacs-21.2.9x)?

    - What's the official way to distinguish Emacs-21.3 from the current
      development versions (Emacs-21.3.50.X)?

For pre-releases and development versions, emacs-version contains four
digits, for official releases, it contains three (the last digit each
time only makes sense to the user).

Sincerely,

Luc.

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

[Richard Stallman]

     - What's the official way to distinguish Emacs-21.2 from the Emacs-21.3
       pre-releases (Emacs-21.2.9x)?

There isn't one; I don't think we don't need one.

     - What's the official way to distinguish Emacs-21.3 from the current
       development versions (Emacs-21.3.50.X)?

There isn't one, and perhaps it would be useful to have one.
Perhaps if we implement emacs-version>= you could test for a version
larger than 21.3.  (This assumes that the third version number
created by dumping does not count.)