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