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 15:57:35 -0500 Message-ID: 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 1260392276 11929 80.91.229.12 (9 Dec 2009 20:57:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Dec 2009 20:57:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 09 21:57:48 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 1NITbU-0005LU-Fw for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 21:57:44 +0100 Original-Received: from localhost ([127.0.0.1]:43863 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NITbU-0008Dd-BX for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 15:57:44 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NITbP-0008Cp-CX for emacs-devel@gnu.org; Wed, 09 Dec 2009 15:57:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NITbL-00089k-QO for emacs-devel@gnu.org; Wed, 09 Dec 2009 15:57:39 -0500 Original-Received: from [199.232.76.173] (port=35142 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NITbL-00089h-Lj for emacs-devel@gnu.org; Wed, 09 Dec 2009 15:57:35 -0500 Original-Received: from mail2.panix.com ([166.84.1.73]:49407) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NITbL-00052n-7u for emacs-devel@gnu.org; Wed, 09 Dec 2009 15:57:35 -0500 Original-Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail2.panix.com (Postfix) with ESMTP id 3193038E46; Wed, 9 Dec 2009 15:57:35 -0500 (EST) Original-Received: from mail.panix.com (localhost [127.0.0.1]) by mailbackend.panix.com (Postfix) with ESMTP id A064C2D47E; Wed, 9 Dec 2009 15:57:34 -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 15:57:35 -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:118483 Archived-At: > Not sure what you mean by "blank" entries. If you mean entries which > don't get printed (i.e. "invisilbe" entries), then yes, it's > a limitation that it would be good to lift. IIUC you lift it by: Yes, I meant entries that print nothing and have no separator. >> * Design: Nodes that have no text have no start marker. > > which I think is a good solution (when I tried to lift that limitation > it didn't occur to me, so I tried to manually separate the markers that > needed to move from those that needed to stay put and it was messy). I bet it was messy. That was the first approach I tried. >> * ewoc-map is slightly misnamed; it doesn't map, it's more like >> for-each. > > It's the historical name. To fit with other macros (like dotimes, > dolist), we could call it ewoc-do rather than ewoc-foreach. Fair enough. But ISTM that while `ewoc-for-each' can have the same signature as `ewoc-map' has now, `ewoc-do' would be expected to have a signature like dolist and dotimes. Ie, to be used like: (ewoc-do (element ewoc) (do-stuff-to element)) So ewoc-for-each was just an alias but ewoc-do would require more. >> * Added a version number. I didn't have much to go on, so I just >> said it was "2.0". I will gladly change it to correspond to an >> official version number. > > The Emacs package generally doesn't like version numbers, so I'd rather > 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. >> * Added a new field to the ewoc, "separator". That's the string that >> separates entries. It defaults to "\n". > > IIUC it can also be the empty string, right? IIUC, the current ewoc.el > already makes it possible to get rid of the separator. Making it > an argument might be a good idea as well. Yes, I think so too. >> Testing: > >> * Created a test suite. The suite relies on rtest, which >> unfortunately is still between releasable versions. > > 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.=20 (Which, circularly, is the reason I wanted to make ewoc more flexible) >> diff -c -b /home/tehom/emacs-21.4/lisp/emacs-lisp/ewoc.el >> /home/tehom/projects/emtest/lisp/viewe Will emacs 22.2 be sufficient? Tom Breton (Tehom)