* [Suggestion] New function `emacs-version>=' @ 2003-05-02 19:55 Wedler, Christoph 2003-05-02 21:00 ` Juanma Barranquero ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Wedler, Christoph @ 2003-05-02 19:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-02 19:55 [Suggestion] New function `emacs-version>=' Wedler, Christoph @ 2003-05-02 21:00 ` Juanma Barranquero 2003-05-02 21:14 ` Stefan Monnier 2003-05-02 21:16 ` [Suggestion] New function `emacs-version>=' Thien-Thi Nguyen ` (2 subsequent siblings) 3 siblings, 1 reply; 21+ messages in thread From: Juanma Barranquero @ 2003-05-02 21:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-02 21:00 ` Juanma Barranquero @ 2003-05-02 21:14 ` Stefan Monnier 2003-05-02 21:35 ` Juanma Barranquero 2003-05-03 17:48 ` Reiner Steib 0 siblings, 2 replies; 21+ messages in thread From: Stefan Monnier @ 2003-05-02 21:14 UTC (permalink / raw) Cc: Emacs-Devel (E-mail) > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-02 21:14 ` Stefan Monnier @ 2003-05-02 21:35 ` Juanma Barranquero 2003-05-03 11:12 ` Ehud Karni 2003-05-03 17:48 ` Reiner Steib 1 sibling, 1 reply; 21+ messages in thread From: Juanma Barranquero @ 2003-05-02 21:35 UTC (permalink / raw) Cc: Emacs-Devel (E-mail) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-02 21:35 ` Juanma Barranquero @ 2003-05-03 11:12 ` Ehud Karni 2003-05-03 13:54 ` Juanma Barranquero 0 siblings, 1 reply; 21+ messages in thread From: Ehud Karni @ 2003-05-03 11:12 UTC (permalink / raw) Cc: monnier+gnu/emacs -----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----- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-03 11:12 ` Ehud Karni @ 2003-05-03 13:54 ` Juanma Barranquero 2003-05-03 16:08 ` Stephen J. Turnbull 2003-05-04 13:04 ` Richard Stallman 0 siblings, 2 replies; 21+ messages in thread From: Juanma Barranquero @ 2003-05-03 13:54 UTC (permalink / raw) Cc: monnier+gnu/emacs 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-03 13:54 ` Juanma Barranquero @ 2003-05-03 16:08 ` Stephen J. Turnbull 2003-05-04 19:15 ` Juanma Barranquero 2003-05-04 13:04 ` Richard Stallman 1 sibling, 1 reply; 21+ messages in thread From: Stephen J. Turnbull @ 2003-05-03 16:08 UTC (permalink / raw) Cc: monnier+gnu/emacs >>>>> "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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-03 16:08 ` Stephen J. Turnbull @ 2003-05-04 19:15 ` Juanma Barranquero 2003-05-06 11:05 ` Stephen J. Turnbull 0 siblings, 1 reply; 21+ messages in thread From: Juanma Barranquero @ 2003-05-04 19:15 UTC (permalink / raw) Cc: monnier+gnu/emacs 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-04 19:15 ` Juanma Barranquero @ 2003-05-06 11:05 ` Stephen J. Turnbull 0 siblings, 0 replies; 21+ messages in thread From: Stephen J. Turnbull @ 2003-05-06 11:05 UTC (permalink / raw) Cc: monnier+gnu/emacs >>>>> "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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-03 13:54 ` Juanma Barranquero 2003-05-03 16:08 ` Stephen J. Turnbull @ 2003-05-04 13:04 ` Richard Stallman 1 sibling, 0 replies; 21+ messages in thread From: Richard Stallman @ 2003-05-04 13:04 UTC (permalink / raw) Cc: monnier+gnu/emacs 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-02 21:14 ` Stefan Monnier 2003-05-02 21:35 ` Juanma Barranquero @ 2003-05-03 17:48 ` Reiner Steib 2003-05-03 18:42 ` Stefan Monnier 1 sibling, 1 reply; 21+ messages in thread From: Reiner Steib @ 2003-05-03 17:48 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: New function `emacs-version>=' 2003-05-03 17:48 ` Reiner Steib @ 2003-05-03 18:42 ` Stefan Monnier 2003-05-05 13:47 ` sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>=') Reiner Steib 0 siblings, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2003-05-03 18:42 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>=') 2003-05-03 18:42 ` Stefan Monnier @ 2003-05-05 13:47 ` Reiner Steib 2003-05-06 7:08 ` Kenichi Handa 0 siblings, 1 reply; 21+ messages in thread From: Reiner Steib @ 2003-05-05 13:47 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>=') 2003-05-05 13:47 ` sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>=') Reiner Steib @ 2003-05-06 7:08 ` Kenichi Handa 0 siblings, 0 replies; 21+ messages in thread From: Kenichi Handa @ 2003-05-06 7:08 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Suggestion] New function `emacs-version>=' 2003-05-02 19:55 [Suggestion] New function `emacs-version>=' Wedler, Christoph 2003-05-02 21:00 ` Juanma Barranquero @ 2003-05-02 21:16 ` Thien-Thi Nguyen 2003-05-04 13:03 ` Richard Stallman 2003-05-06 23:42 ` Istvan Marko 3 siblings, 0 replies; 21+ messages in thread From: Thien-Thi Nguyen @ 2003-05-02 21:16 UTC (permalink / raw) Cc: Emacs-Devel (E-mail) "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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Suggestion] New function `emacs-version>=' 2003-05-02 19:55 [Suggestion] New function `emacs-version>=' Wedler, Christoph 2003-05-02 21:00 ` Juanma Barranquero 2003-05-02 21:16 ` [Suggestion] New function `emacs-version>=' Thien-Thi Nguyen @ 2003-05-04 13:03 ` Richard Stallman 2003-05-05 12:52 ` Wedler, Christoph 2003-05-06 23:42 ` Istvan Marko 3 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2003-05-04 13:03 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [Suggestion] New function `emacs-version>=' @ 2003-05-05 12:52 ` Wedler, Christoph 2003-05-05 13:20 ` Juanma Barranquero ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Wedler, Christoph @ 2003-05-05 12:52 UTC (permalink / raw) Cc: emacs-devel 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... ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Suggestion] New function `emacs-version>=' 2003-05-05 12:52 ` Wedler, Christoph @ 2003-05-05 13:20 ` Juanma Barranquero 2003-05-05 19:11 ` Richard Stallman 2003-05-05 21:59 ` Luc Teirlinck 2 siblings, 0 replies; 21+ messages in thread From: Juanma Barranquero @ 2003-05-05 13:20 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Suggestion] New function `emacs-version>=' 2003-05-05 12:52 ` Wedler, Christoph 2003-05-05 13:20 ` Juanma Barranquero @ 2003-05-05 19:11 ` Richard Stallman 2003-05-05 21:59 ` Luc Teirlinck 2 siblings, 0 replies; 21+ messages in thread From: Richard Stallman @ 2003-05-05 19:11 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Suggestion] New function `emacs-version>=' 2003-05-05 12:52 ` Wedler, Christoph 2003-05-05 13:20 ` Juanma Barranquero 2003-05-05 19:11 ` Richard Stallman @ 2003-05-05 21:59 ` Luc Teirlinck 2 siblings, 0 replies; 21+ messages in thread From: Luc Teirlinck @ 2003-05-05 21:59 UTC (permalink / raw) Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Suggestion] New function `emacs-version>=' 2003-05-02 19:55 [Suggestion] New function `emacs-version>=' Wedler, Christoph ` (2 preceding siblings ...) 2003-05-04 13:03 ` Richard Stallman @ 2003-05-06 23:42 ` Istvan Marko 3 siblings, 0 replies; 21+ messages in thread From: Istvan Marko @ 2003-05-06 23:42 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2003-05-06 23:42 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-05-02 19:55 [Suggestion] New function `emacs-version>=' Wedler, Christoph 2003-05-02 21:00 ` Juanma Barranquero 2003-05-02 21:14 ` Stefan Monnier 2003-05-02 21:35 ` Juanma Barranquero 2003-05-03 11:12 ` Ehud Karni 2003-05-03 13:54 ` Juanma Barranquero 2003-05-03 16:08 ` Stephen J. Turnbull 2003-05-04 19:15 ` Juanma Barranquero 2003-05-06 11:05 ` Stephen J. Turnbull 2003-05-04 13:04 ` Richard Stallman 2003-05-03 17:48 ` Reiner Steib 2003-05-03 18:42 ` Stefan Monnier 2003-05-05 13:47 ` sort-coding-systems in 21.3 and RC branch (was: New function `emacs-version>=') Reiner Steib 2003-05-06 7:08 ` Kenichi Handa 2003-05-02 21:16 ` [Suggestion] New function `emacs-version>=' Thien-Thi Nguyen 2003-05-04 13:03 ` Richard Stallman 2003-05-05 12:52 ` Wedler, Christoph 2003-05-05 13:20 ` Juanma Barranquero 2003-05-05 19:11 ` Richard Stallman 2003-05-05 21:59 ` Luc Teirlinck 2003-05-06 23:42 ` Istvan Marko
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.