D19367: [RFC]SearchBar: Don't block GUI when enter incremental pattern
Christoph Cullmann
noreply at phabricator.kde.org
Mon Mar 4 19:19:40 GMT 2019
cullmann added a comment.
In D19367#424714 <https://phabricator.kde.org/D19367#424714>, @loh.tar wrote:
> > The batch processing approach is sane.
>
> hm, thanks
>
> > My real issue here is: What to do with multi-line expressions that might span more than one line? Won't we miss matches if the ranges just overlap at that locations?
>
> Well, yes...that should be the case. I had also some idea but ...
>
> > not compute the batch ranges beforehand
>
> ...that sound not so nice. What if I would keep it but find some solution?
I am not sure that the precomputation saves you a lot of things, you can your compute the next batch in the slot that searches.
But if the issue with the multi-line stuff is solved, I won't t reject this for the precomputation, this still can be "optimized" later on if wanted.
> OTH is that multiline search for me a slightly rare case
Yes, that is true.
It should just work reasonable well, if would be bad if e.g. even a trivial case like lala\nlala would break because of badly choosen boundaries.
REPOSITORY
R39 KTextEditor
REVISION DETAIL
https://phabricator.kde.org/D19367
To: loh.tar, #ktexteditor, dhaumann, cullmann
Cc: cullmann, kwrite-devel, kde-frameworks-devel, #ktexteditor, domson, michaelh, ngraham, bruns, demsking, sars, dhaumann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190304/b75b1b82/attachment.html>
More information about the Kde-frameworks-devel
mailing list