bug#13648: 24.3.50; remove-overlays bugs

[Stefan Monnier]

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

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


        Stefan