Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers

[Juri Linkov]

> The other approach, which the below patch implements, is try to find the
> bounds based on the strings, but if the contents been edited, find the
> nearest CRM separator. This is kind of nice in that it lets you edit
> other selections but then still select a candidate, but I don't know how
> useful/expected that really is. The logic could also be made somewhat
> more complex (count the number of separators in `start` and `end`, try
> to guess how many we should skip over in each direction) but I don't
> know if that's really worthwhile.

I tried out this approach and it works nicely, except the case
when the CRM separator gets deleted by the user.  But OTOH,
the user might want to delete the separator intentionally,
to reduce the number of selections.  So it seems there is no need
to make the logic more complex.