bug#13648: 24.3.50; remove-overlays bugs

[Stephen Berman]

On Thu, 07 Feb 2013 11:42:46 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> 
wrote:

>> The reason for the first problem is that remove-overlays tests the
>> overlay value with eq, which fails for all strings [...]
>
> No, it won't fail on all strings.  You just need to pass it the same
> string you added to the overlay, rather than a copy of it.
> I.e. this is not a bug.

Damn, I get tripped up by that a lot.  And the fact that the empty
string is an exception doesn't help to keep the difference in mind.
Still, it is rather cumbersome to include appropriate let-bindings or
calls to overlay-get for each string value in each use of
remove-overlays, as opposed to adding a single equal-check to that.

>> invocation of remove-overlays is legitimate), the logic of the code is
>> that the NAME and VAL arguments are either both nil or both non-nil,
>
> Indeed.
>
>> which conflicts with the semantics of the &optional keyword.
>
> Right.  We should document it in the docstring.
>
>> This means that the last call of remove-overlays in the above sexp
>> would clear any after-string overlays, regardless of their value.
>
> Normally we don't distinguish "an property FOO of value nil" and "no
> property FOO".  So I think what would make sense is to say that if VAL
> is nil, then we remove any overlay whose NAME property is non-nil
> (i.e. the exact inverse from what we currently do).
>
> This said, the reason why I have not implemented this case of NAME being
> specified while VAL is left unspecified is because I haven't come up
> with a need for it.  So I'd be interested to hear the backstory of
> why/where you need it.

To be honest, I'm not sure I do need it.  I have code that inserts
before-string overlays with different values, some fixed and some
dynamically generated, and when these overlays need to be cleared, it
would be easier to just refer to the before-string property.  But the
way I use the overlays, it actually suffices to leave out both the
property and the value, i.e. just remove all overlays in the region.  At
first I thought that's not safe enough, because there could be other
other overlays at the same locations but with different properties, but
in fact I haven't needed that yet.  But I guess the main thing that
confused me was the conflict with the semantics of &optional, and since
it seems easy enough to avoid, I think it would be better than just
documenting the conflict.

Steve Berman