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: New function `emacs-version>=' Date: Fri, 02 May 2003 23:35:14 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20030502232146.C2FF.LEKTU@terra.es> References: <20030502224227.C2FC.LEKTU@terra.es> <200305022114.h42LE8PH022578@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1051911722 26091 80.91.224.249 (2 May 2003 21:42:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 2 May 2003 21:42:02 +0000 (UTC) Cc: "Emacs-Devel \(E-mail\)" Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 02 23:41:58 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19BiI2-0006mG-00 for ; Fri, 02 May 2003 23:41:58 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19BiJl-0008KG-00 for ; Fri, 02 May 2003 23:43:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19BiGZ-0007QD-04 for emacs-devel@quimby.gnus.org; Fri, 02 May 2003 17:40:27 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19BiEl-0006by-00 for emacs-devel@gnu.org; Fri, 02 May 2003 17:38:35 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19BiEO-0006Ls-00 for emacs-devel@gnu.org; Fri, 02 May 2003 17:38:12 -0400 Original-Received: from smtp.terra.es ([213.4.129.129] helo=tsmtp2.mail.isp) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19BiBY-0004dy-00 for emacs-devel@gnu.org; Fri, 02 May 2003 17:35:16 -0400 Original-Received: from [193.153.116.104] ([193.153.116.104]) by tsmtp2.mail.isp (terra.es) with ESMTP id HEA3YP00.9YQ; Fri, 2 May 2003 23:35:13 +0200 Original-To: "Stefan Monnier" In-Reply-To: <200305022114.h42LE8PH022578@rum.cs.yale.edu> X-Mailer: Becky! ver. 2.05.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13634 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13634 On Fri, 02 May 2003 17:14:07 -0400, "Stefan Monnier" 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