Re: ewoc patch

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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.

Keep only `separator', but with the added twist that a non-string,
non-nil argument means the empty string (aka mean "nosep").  That should
preserve backward compatibility with a mostly clean API.

>>>> 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.

I think you're worrying for no good reason.  If you really want to
handle version dependencies right, you don't want it in a Lisp variable
but in a header understood and processed by some package manager (ELPA,
for instace).  Otherwise, you'll have to deal (one way or another) with
runtime checks, and in most cases the calling package will simply not
work with an older version.


        Stefan