From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Tom Breton (Tehom)" Newsgroups: gmane.emacs.devel Subject: Re: ewoc patch Date: Wed, 9 Dec 2009 23:52:56 -0500 Message-ID: <08698ba442eec12008bede6987588958.squirrel@mail.panix.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1260420795 25827 80.91.229.12 (10 Dec 2009 04:53:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Dec 2009 04:53:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 10 05:53:07 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NIb1X-0001sV-Bj for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2009 05:53:07 +0100 Original-Received: from localhost ([127.0.0.1]:45650 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIb1X-0000UU-9z for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 23:53:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIb1S-0000Ts-NE for emacs-devel@gnu.org; Wed, 09 Dec 2009 23:53:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIb1O-0000Rp-7h for emacs-devel@gnu.org; Wed, 09 Dec 2009 23:53:02 -0500 Original-Received: from [199.232.76.173] (port=51651 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIb1O-0000Rm-5B for emacs-devel@gnu.org; Wed, 09 Dec 2009 23:52:58 -0500 Original-Received: from mail2.panix.com ([166.84.1.73]:59532) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NIb1N-0007mK-SC for emacs-devel@gnu.org; Wed, 09 Dec 2009 23:52:57 -0500 Original-Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail2.panix.com (Postfix) with ESMTP id 9499D38E44; Wed, 9 Dec 2009 23:52:56 -0500 (EST) Original-Received: from mail.panix.com (localhost [127.0.0.1]) by mailbackend.panix.com (Postfix) with ESMTP id 510572DBAB; Wed, 9 Dec 2009 23:52:56 -0500 (EST) X-Panix-Received: from 96.252.49.112 (SquirrelMail authenticated user tehom@panix.com) by mail.panix.com with HTTP; Wed, 9 Dec 2009 23:52:56 -0500 In-Reply-To: User-Agent: SquirrelMail/1.4.19 X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:118512 Archived-At: I have, as you asked, adapted my changes for the latest CVS ewoc, for emacs 23.1. A few remarks: How do you prefer to handle the part of the ewoc-create interface that gives separator? I can see several ways of proceeding: * Add another optional argument. So there'd be both "nosep" and "separator" * Con: It's ugly to have 2 arguments with strongly overlapping meanings. * Con: Confusing if the given arguments disagree. * Replace argument "nosep" with "separator" * Con: Breaks backward compatibility. * Pro: Suffices to control all the variability * Keep only "nosep" as an argument. * Con: The flexibility is not available, though it exists internally. * Provide two function signatures; maybe name the other `ewoc-create*'. * Con: Makes the interface a little bigger. >>> The Emacs package generally doesn't like version numbers, so I'd rath= er >>> not introduce one here, unless there's really a good reason for it. >> I added it so that other packages that wanted or needed a variable >> separator could tell whether it was available. Otherwise they would >> make >> errors if an old ewoc.el was loaded. If you have a better way in mind= , >> I'll use it. > > Better just try to use the feature and detect when it's not available. > E.g. check the feature's presence via `fboundp' or by trying the call > with the extra parametwer and catch the > `wrong-number-of-arguments' error. I'm not sure that would suffice. ewoc-create is fbound in any case. Tha= t leaves us with trying ewoc-create and catching the error. My fear is tha= t a client's call to ewoc-create would not naturally occur at a good time for this. Ie, a client would appear to load correctly, would be started by the user, and only then realize that it was relying on something that wasn't available. >>> We still don't have a testsuite in Emacs, but we'll gladly add the >>> testsuite to our repository (we have a `test' subdirectory for that). >> Sure. But it uses my tester package rtest; there is an old version of >> rtest out there but I'm using my new version that is still in flux. >> (Which, circularly, is the reason I wanted to make ewoc more flexible) > > I understand. It's OK if the tests can't be run as-is. OK. I just added tests for ewoc-do as well. I will submit the test code= . Thanks for your help, Tom Breton (Tehom)