Version: unspecified (using Devel) OS: Linux When entering text in the search-text-field the search is executed in the Main/UI-Thread. For large files (20-30mb) this is very slow, often it takes several seconds for characters to appear when writing into the search-text-field. Reproducible: Didn't try Steps to Reproduce: 1. Open large text-file (20-30mb) 2. Open the search panel (Ctrl+F) 3. Enter some search-input which does not exist in the opend text-file Actual Results: Every character input triggers a search, which prevents the application from processing further inputs fluently. Expected Results: The search should be performed in a background thread which does not block the UI. All capable text-enditors and IDEs work that way.
This is probably a WONT-FIX. Other Kate-Devs?
A thread might be hard to implement, but we could try to do a bit magic with the event loop and only search in batches. That would make it more responsive without much additional complexity.
Kate is great but this problem mars a whole work. I check logs which are pretty large, and it is not convinient to type the searching phrase in other tab and often I forget to do this first, so I need to wait 20-30 seconds until it finishes searching first 3 letters. And it is rememberable so if the target is to make a tool that is better than others then would be better to fix this issue. I spend my 20 votes because I think it is important problem. Again, kate is great, may be the best tool i've seen. I really like it. But the searching is a problem.
Imo this is an issue and should be solved. One simple way would be to delay the search until no new chars are inserted, i.e. 500ms or something. Of course additionally it would be cool to reenter the eventloop for short times during searching. I know it is possible, just never did anything like that myself.
I'd suggest to not do the 'run the eventloop for short times during searching' as this often enough causes more headaches than is useful. The reason is that usually the code then expects its running through once and in the middle doing some event-processing, but suddenly there's also a chance the search-code is re-entered... So its better to write it from the start such that it can be re-entered as Christoph said doing the search in batches. Maybe the blocks that kate splits the document into would be easily usable for this, i.e. search in one block, schedule a single-shot-timer to search the next block etc....
Still this is no bug, but a wish. I would like to have it, too, but I think this will need take some time until somebody steps up to do this.
*** Bug 252020 has been marked as a duplicate of this bug. ***
In the search & replace plugin I have solved it by limiting the "as you type" search to 100 ms. Then when you apply the search it searches in bathes of max 100 ms.
Yeah, such a fix would be highly appreciated for the integrated search, too.
*** Bug 402361 has been marked as a duplicate of this bug. ***
Git commit 7cf6644e8017e6b04898f2d68a9db766d1d95f44 by Christoph Cullmann, on behalf of loh tar. Committed on 20/01/2019 at 12:46. Pushed by cullmann into branch 'master'. SearchBar: Add Cancel button to stop long running tasks Summary: Without this patch could it happens that Kate run an almost endless S&R job which could lead up to an unusable system due to a run out of memory with no possibility to cancel the job other than kill Kate, See... Related: bug 333517 Test Plan: Before {F6466371} New waiting for action {F6466378} New while running job {F6466380} Reviewers: #ktexteditor, #vdg, cullmann Reviewed By: #ktexteditor, cullmann Subscribers: dhaumann, anthonyfieroni, brauch, cullmann, abetts, kwrite-devel, kde-frameworks-devel, #ktexteditor Tags: #kate, #frameworks Differential Revision: https://phabricator.kde.org/D17459 M +144 -75 src/search/katesearchbar.cpp M +42 -7 src/search/katesearchbar.h M +170 -156 src/search/searchbarpower.ui https://commits.kde.org/ktexteditor/7cf6644e8017e6b04898f2d68a9db766d1d95f44
*** Bug 339337 has been marked as a duplicate of this bug. ***
https://phabricator.kde.org/D19367
If somebody steps up to test and finalize https://phabricator.kde.org/D19367 this will be fixed soon!
A couple of points/thoughts: - It's a given that search has to block editing the document - For large files, size > 10-20MB, disable "search as you type" , and inform the user about that; the user will have to press Enter after typing the search text. That gets rid of the behaviour in this report i.e. "typed characters take a couple of seconds to appear in the search box" - If searching takes more than some preset time (probably the same time limit that's been implemented after which the "Cancel" button is displayed when searching), display a message e.g. "Searching..." while the search is being performed and the GUI is being blocked - The same thing should be done for power search as the GUI blocks when searching for even just one next match, in a big file
? The patch https://phabricator.kde.org/D19367 batches the search exactly to avoid that either the gui blocks or we need to disable "search as you type" even for large documents. Have you given it a try?
Marking this as resolved since after the recent fixes (in last couple of releases), our search is fast enough for files of a few hundred megabytes.