From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: No calc in pretest? Date: Tue, 02 Jul 2002 11:50:42 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <20020702113707.5BED.LEKTU@terra.es> References: <5x8z4upiqs.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1025603550 24259 127.0.0.1 (2 Jul 2002 09:52:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2002 09:52:30 +0000 (UTC) Cc: Miles Bader , Francesco Potorti` , Jon Cast , Eli Zaretskii , burton@openprivacy.org, Emacs Devel Mailing List Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17PKKk-0006JA-00 for ; Tue, 02 Jul 2002 11:52:30 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17PKPi-0006Pp-00 for ; Tue, 02 Jul 2002 11:57:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PKJS-00012D-00; Tue, 02 Jul 2002 05:51:10 -0400 Original-Received: from [62.22.27.141] (helo=mail.peoplecall.com) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PKJ8-00010l-00; Tue, 02 Jul 2002 05:50:50 -0400 Original-Received: from [62.22.27.143] (jbarranquero.ofi.peoplecall.com [62.22.27.143]) by mail.peoplecall.com (8.11.6/8.11.6) with ESMTP id g629oee00360; Tue, 2 Jul 2002 11:50:40 +0200 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: <5x8z4upiqs.fsf@kfs2.cua.dk> X-Mailer: Becky! ver. 2.05 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5313 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5313 On 02 Jul 2002 11:43:55 +0200, storm@cua.dk (Kim F. Storm) wrote: > I don't know any code which breaks because of this though. Not very significative, I know, but my .emacs is an example ;-) I update my .emacs frequently and share it between GNU/Linux, Windows 95 and Windows 2K, and between 20.7, 21.1, 21.2, EMACS_21_1_RC and HEAD releases/versions. I have the following code in it, just to support checking the version and system: (defconst lk-emacs-sub-version (save-match-data (string-match "^[0-9]+\\.[0-9]+\\.\\([0-9]+\\)" emacs-version) (string-to-int (match-string 1 emacs-version))) "Sub-version number of this version of Emacs.") (defun lk-check-version (major &rest arguments) "Check Emacs version. By default it checks that `emacs-major-version' is greater or equal than MAJOR. ARGUMENTS can include a minor version number (to check against `emacs-minor-version'), a subversion number (for version numbers of the form 21.X.Y), and a test function to replace the default >= check." (let ((minor nil) (sub nil) (test #'>=)) (dolist (value arguments) (cond ((numberp value) (if minor (setq sub value) (setq minor value))) ((functionp value) (setq test value)) (t (error "wrong argument list %s" arguments)))) (and (funcall test emacs-major-version major) (or (not minor) (funcall test emacs-minor-version minor)) (or (not sub) (funcall test lk-emacs-sub-version sub))))) (defmacro on-system (variable &rest arguments) `(let ((result nil)) (while (and arguments (not result)) (let ((system (caar arguments))) (if (or (and (listp system) (memq ,variable system)) (eq system t) (eq system ,variable)) (setq result (cdar arguments)) (setq arguments (cdr arguments))))) (and result (cons 'progn result)))) (defmacro on-window-system (&rest arguments) (on-system window-system arguments)) (defmacro on-system-type (&rest arguments) (on-system system-type arguments)) And then I do things like (when (lk-check-version 21 2 50) ...) which break on release renumberings. (Yeah, I use fboundp and featurep, etc., but sometimes the changes are functional and checking the version is the only option.) A more logical way to numbering releases would be welcome. Still, I dislike the even/odd convention, because it is obvious to programmers and people who follows closely the software development cycle, but not so obvious to casual users and/or non-programmers. On the same vein, upping the release to 22 doesn't seem like a good idea to me. Emacs went from 19.X to 20.X when it incorpored MULE, I think, and from it to 21.X with a new and much better redisplay engine able to support images and non-proportional fonts and you-name-it. Those aren't just incremental changes. I'd expect 22.X to be the full-Unicode-support release :) /L/e/k/t/u