Re: ewoc patch

["Tom Breton (Tehom)" <tehom@panix.com>]

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 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.
>
> 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.  That
leaves us with trying ewoc-create and catching the error.  My fear is that
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)