[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Handle case where `beg` and `end` are strings instead of mar
From: |
James N . V . Cash |
Subject: |
Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers |
Date: |
Wed, 04 May 2022 17:09:27 -0400 |
Juri Linkov <juri@linkov.net> writes:
>>>> 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.
It's been working okay for me for the past few days & I do indeed have a
copyright assignment on file. Thanks!
James