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

[Juanma Barranquero]

On Fri, 2 May 2003 21:55:31 +0200 , "Wedler, Christoph" <christoph.wedler@sap.com> wrote:

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

I used to think like you, and even had such a function in my .emacs (to
cope with 20.7, 21.[123], 21.2.9[0-5], EMACS_21_1_RC and HEAD).

Now I don't. You say:

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

but the right test is:

 - I want to use feature/fix A
 - therefore, I test whether A is available.

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). Checking for a
particular release is pointless, because you're not really interested in
the release, you're interested in the feature.

What's wrong with using fboundp, boundp, facep? There are 23/11/6 of
them (respectively) in my .emacs and it works really fine...

                                                           /L/e/k/t/u

Re: New function `emacs-version>='

[Stefan Monnier]

> but the right test is:
> 
>  - I want to use feature/fix A
>  - therefore, I test whether A is available.

I think Christoph knows that.  It's just that sometimes it's difficult
to test whether A works or not.  For instance, how do you check whether
the `display' property is supported by your version of Emacs ?
How do you test whether PNG images are supported (without actually
displaying such an image) ? ...

In most cases, there's a better solution than testing emacs-version, but
there are still some where testing emacs-version makes sense and furthermore
people do it anyway, so I'd rather provide an `emacs-version>=' rather than
see something fail in Emacs-21 because some idiot wrote
(or (= 20 emacs-major-version) (>= 29 emacs-minor-version)).

And then we can make bytecomp.el emit warning messages about
how you shouldn't use that function ;-)


	Stefan

Re: New function `emacs-version>='

[Juanma Barranquero]

On Fri, 02 May 2003 17:14:07 -0400, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> I think Christoph knows that.

Sure, I didn't intend to imply otherwise. Rhetoric took hold of me :(

> It's just that sometimes it's difficult
> to test whether A works or not.  For instance, how do you check whether
> the `display' property is supported by your version of Emacs ?

Yeah, sure. But most features are not isolated, there are related
variables, functions and sometimes even an entry in `features'... And if
not, I'd call that a bug in the feature/fix implementation (I'm
exaggerating, but only a bit.)

And, as a last resort, you can often do something like

  (unless (ignore-errors XXXX)
    YYYY)

(I do that to check whether windmove-default-keybindings supports the
MODIFIER argument or not.)

> How do you test whether PNG images are supported (without actually
> displaying such an image) ? ...

(memq 'png image-types)   ; :-)

> In most cases, there's a better solution than testing emacs-version, but
> there are still some where testing emacs-version makes sense and furthermore
> people do it anyway, so I'd rather provide an `emacs-version>=' rather than
> see something fail in Emacs-21 because some idiot wrote
> (or (= 20 emacs-major-version) (>= 29 emacs-minor-version)).

I'm not going to oppose that, but I'd bet is going to bring more grief
than help. I can speak only about my very subjective experience, and
certainly my .emacs (1,600+ lines) is more robust now than before, when
I used several flavors of emacs and window-system checking.

> And then we can make bytecomp.el emit warning messages about
> how you shouldn't use that function ;-)

Eh, I *like* that ;-)

                                                           /L/e/k/t/u

Re: New function `emacs-version>='

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 02 May 2003 23:35:14 +0200, Juanma Barranquero <lektu@terra.es> wrote:
> 
> On Fri, 02 May 2003 17:14:07 -0400, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
> 
> > It's just that sometimes it's difficult
> > to test whether A works or not.  For instance, how do you check whether
> > the `display' property is supported by your version of Emacs ?
> 
> Yeah, sure. But most features are not isolated, there are related
> variables, functions and sometimes even an entry in `features'... And if
> not, I'd call that a bug in the feature/fix implementation (I'm
> exaggerating, but only a bit.)
> 
> And, as a last resort, you can often do something like
> 
>   (unless (ignore-errors XXXX)
>     YYYY)

That is NOT always possible, I have another actual example:
How do you check that `perform-replace' accept a function in its
REPLACEMENTS argument (id does in 21.x, does not in 20.x or lower) ?

I have a hacked `perform-replace-20' (which is not the same as the 
current version) function for older emacs's and I do:
    (if (< emacs-major-version 21)
        (defalias 'perform-replace 'perform-replace-20))

please suggest a better way.

Ehud.


- -- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE+s6QILFvTvpjqOY0RAv4GAJ0RHsSfJ0aNVElMgYAHDXV5z64BBwCeIAvn
GZvWUHM04ex9P10bz8Clpr8=
=HykV
-----END PGP SIGNATURE-----

Re: New function `emacs-version>='

[Juanma Barranquero]

On Sat, 3 May 2003 14:12:09 +0300, "Ehud Karni" <ehud@unix.mvs.co.il> wrote:

> > And, as a last resort, you can often do something like
> > 
> >   (unless (ignore-errors XXXX)
> >     YYYY)
> 
> That is NOT always possible

Yeah, well, that's perhaps the reason I wrote "you can *often* do..." :-)

But, honestly, how many cases like this one have you found?

> I have another actual example:
> How do you check that `perform-replace' accept a function in its
> REPLACEMENTS argument (id does in 21.x, does not in 20.x or lower) ?

OK, how do you check that if Emacs does not include emacs-version>= and
will not till 21.4, at the very least? What I mean is that Emacs does
*not* have the function, so you'll be stuck with custom-made checks for
a long time, unless you (as a module author, I mean) are going to drop
support for 21.3- releases. Any answer to the situation is forward
looking, and for that, it's better to be sure any such new change and/or
feature can be properly detected. It's more robust.

OTOH, the use of a function as REPLACEMENTS is not even documented, and
the docstring for `perform-replace' suggests not using the function, so
it's not a very compelling example IMO.

                                                           /L/e/k/t/u

Re: New function `emacs-version>='

[Stephen J. Turnbull]

>>>>> "Juanma" == Juanma Barranquero <lektu@terra.es> writes:

    Juanma> Yeah, well, that's perhaps the reason I wrote "you can
    Juanma> *often* do..." :-)

    Juanma> But, honestly, how many cases like this one have you
    Juanma> found?

Isn't one enough?  :-)

The XEmacs Review practice wrt to emacs-version>= is to query the
patch author if a feature test couldn't be used instead.  About half
the time in my experience the author makes a reasonable case (eg, if a
package depends on multiple features that all came available with a
certain version).

I like Stefan's idea though; I think I'm going to implement it.  It
should sufficiently annoy people that they'll book up on Ben's new
suite of warning control APIs, too.  :-)

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: New function `emacs-version>='

[Juanma Barranquero]

On Sun, 04 May 2003 01:08:46 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> Isn't one enough?  :-)

Yeah, it is, for some definition of enough :-)

> The XEmacs Review practice wrt to emacs-version>= is to query the
> patch author if a feature test couldn't be used instead.  About half
> the time in my experience the author makes a reasonable case (eg, if a
> package depends on multiple features that all came available with a
> certain version).

Wouldn't, in that case, be enough to test for just *one* of these
multiple features?

> I like Stefan's idea though; I think I'm going to implement it.  It
> should sufficiently annoy people that they'll book up on Ben's new
> suite of warning control APIs, too.  :-)

:-)

But, honestly: I'm not deadly opposed to emacs-version>=, it's just I
think most of the time it's the wrong test. Adding the function amounts
to encouraging its use, unless Stefan's idea (or any strong variant) is
also implemented.

                                                           /L/e/k/t/u

Re: New function `emacs-version>='

[Stephen J. Turnbull]

>>>>> "Juanma" == Juanma Barranquero <lektu@terra.es> writes:

    Juanma> But, honestly: I'm not deadly opposed to emacs-version>=,
    Juanma> it's just I think most of the time it's the wrong
    Juanma> test. Adding the function amounts to encouraging its use,
    Juanma> unless Stefan's idea (or any strong variant) is also
    Juanma> implemented.

Then we're basically in agreement.

Christoph Wedler's point about "forward" compatibility when one
implementation or another has an API and the other does not, and might
define it differently is also important.  I think cooperation of the
kind that has occurred on `split-string' can reduce the number of such
cases and thus increase the applicability of f?boundp tests, but this
will take time.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: New function `emacs-version>='

[Richard Stallman]

    OTOH, the use of a function as REPLACEMENTS is not even documented, and
    the docstring for `perform-replace' suggests not using the function, 

The doc string does not "suggest not using this function."  It says
that you should not use this function when what you want is a simple
search and replace loop.

Re: New function `emacs-version>='

[Reiner Steib]

On Fri, May 02 2003, Stefan Monnier wrote:

> It's just that sometimes it's difficult to test whether A works or
> not.

Another example (BTW: Is this fixed in the RC branch?):

Gnus 5.9 bundled with Emacs 21.3 comes with a slightly broken version
of the function `sort-coding-systems'.  Therefore in some cases, Gnus
uses utf-16-x rather than utf-8.  Additionally, it's not correct
utf-16-be.  (See [1] for details.)

My current test is...

(when (featurep 'xemacs)
  (error (concat "This file cannot be used with XEmacs.")))
(defun rs-sort-coding-systems (codings) [... fixed code ...])
(if (and (= emacs-major-version 21) (= emacs-minor-version 3))
    (defalias 'sort-coding-systems 'rs-sort-coding-systems)
  (message "[...]"))

Okay, here I'd need `emacs-version=', rather than emacs-version>='.
But I don't see a better test than emacs-version.

Bye, Reiner.

[1] <v9adfeig1c.fsf@marauder.physik.uni-ulm.de> on bug-gnu-emacs,
<URL:http://news.gmane.org/onethread.php?group=gmane.emacs.bugs&root=%3Cv9adfeig1c.fsf@marauder.physik.uni-ulm.de%3E>

-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: New function `emacs-version>='

[Stefan Monnier]

> On Fri, May 02 2003, Stefan Monnier wrote:
> 
> > It's just that sometimes it's difficult to test whether A works or
> > not.
> 
> Another example (BTW: Is this fixed in the RC branch?):
> 
> Gnus 5.9 bundled with Emacs 21.3 comes with a slightly broken version
> of the function `sort-coding-systems'.  Therefore in some cases, Gnus
> uses utf-16-x rather than utf-8.  Additionally, it's not correct
> utf-16-be.  (See [1] for details.)

Have you tried to test something like

 (eq 'mule-utf-16-be (car (sort-coding-systems '(mule-utf-8 mule-utf-16-be))))


-- Stefan

sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>=')

[Reiner Steib]

On Sat, May 03 2003, Stefan Monnier wrote:

>> Another example (BTW: Is this fixed in the RC branch?):

I've checked it now.  It isn't fixed in RC.  Could someone please
install this patch (see below) in the RC branch?  It's the output of
"diff -u -r1.216 -r1.217 mule-cmds.el" in HEAD.
 
>> Gnus 5.9 bundled with Emacs 21.3 comes with a slightly broken version
>> of the function `sort-coding-systems'.[...]
>
> Have you tried to test something like
>
>  (eq 'mule-utf-16-be (car (sort-coding-systems '(mule-utf-8
>  mule-utf-16-be))))

No, I haven't.  Thanks for the hint.

But your test is not sufficient:

,----[ b0rked `sort-coding-systems' ]
| ELISP> (sort-coding-systems '(mule-utf-8 mule-utf-16-be))
| (mule-utf-8 mule-utf-16-be)
| ELISP> emacs-version
| "21.3.1"
`----

`find-coding-systems-region' returns, e.g.
(mule-utf-16-be mule-utf-16-le mule-utf-8 compound-text ...).

And the b0rked (21.3.1) version of `sort-coding-systems' doesn't
sort the list correctly:

,----[ b0rked `sort-coding-systems' ]
| ELISP> (sort-coding-systems '(mule-utf-16-be mule-utf-16-le mule-utf-8))
| (mule-utf-16-be mule-utf-16-le mule-utf-8)
`----

The fixed version (e.g. in HEAD) gives:

,----[ Fixed `sort-coding-systems' ]
| ELISP> (sort-coding-systems '(mule-utf-16-be mule-utf-16-le mule-utf-8))
| (mule-utf-8 mule-utf-16-be mule-utf-16-le)
`----

So using '(mule-utf-16-be mule-utf-16-le mule-utf-8) in your
suggestion does the trick:

(eq 'mule-utf-8
    (car (sort-coding-systems
	  '(mule-utf-16-be mule-utf-16-le mule-utf-8))))

(I don't know if mule-utf-16-le is necessary, at least it doesn't
hurt.)

Thanks for suggestion!

Bye, Reiner.

--8<---------------cut here---------------start------------->8---
--- mule-cmds.el	26 Dec 2002 17:27:20 -0000	1.216
+++ mule-cmds.el	3 Jan 2003 20:16:11 -0000	1.217
@@ -425,9 +425,18 @@
 		    (let ((base (coding-system-base x)))
 		      (+ (if (eq base most-preferred) 64 0)
 			 (let ((mime (coding-system-get base 'mime-charset)))
+			   ;; Prefer coding systems corresponding to a
+			   ;; MIME charset.
 			   (if mime
-			       (if (string-match "^x-" (symbol-name mime))
-				   16 32)
+			       ;; Lower utf-16 priority so that we
+			       ;; normally prefer utf-8 to it, and put
+			       ;; x-ctext below that.
+			       (cond ((or (eq base 'mule-utf-16-le)
+					  (eq base 'mule-utf-16-be))
+				      16)
+				     ((string-match "^x-" (symbol-name mime))
+				      8)
+				     (t 32))
 			     0))
 			 (if (memq base lang-preferred) 8 0)
 			 (if (string-match "-with-esc$" (symbol-name base))
--8<---------------cut here---------------end--------------->8---
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>=')

[Kenichi Handa]

In article <v9issp8pzl.fsf_-_@marauder.physik.uni-ulm.de>, Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
> I've checked it now.  It isn't fixed in RC.  Could someone please
> install this patch (see below) in the RC branch?  It's the output of
> "diff -u -r1.216 -r1.217 mule-cmds.el" in HEAD.
 
[...]

I've just installed that in RC.

I've also installed a fix to utf-16.  Although it's
embarrassing to change the behaviour of coding systems, it's
quite confusing to have coding systems utf-16-le and
utf-16-be which are different from the mime charset UTF-16LE
and UTF-16BE respectively as to the handling of leading
signature bytes (BOM: Byte Order Mark).

---
Ken'ichi HANDA
handa@m17n.org

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>='

[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>='

[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>='

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