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.
>
> Should I make a new thread with this patch then, or is the one here okay?

If you think your latest patch is safe enough to install and
you signed a copyright assignment for your changes, I could push it
without the need to create a bug report.