When searching for short strings or numbers, occurrences that are part of a word are not highlighted. For example, when searching for "25" in a table, places where 25 occurs as a whole word (i.e. with spaces or dots before or after it) are highlighted, but e.g. in "250ns" the 25 won't be. The real problem now is that search and replace will still replace the "25" in "250ns". Reproducible: Always Steps to Reproduce: 1. Search for a short string in a text file that contains the search string both as whole words and as part of a word. 2. Use search and replace interactively to replace certain occurrences of the search string. Actual Results: Occurrences that are part of a word are not highlighted by the search, but replaced when using search and replace. Expected Results: Search and replace and search result highlighting should be consistent.
I did digg into this problem yesterday independently of your bug report (because it was driving me nuts). But really thank you for your report. I didn't realized for example the additional induced servere problem with the "replace all" functionality. My research showed the following until now: - The related component is not kate, but KTexteditor (it happens also in KDevelop for example) - Working highlighting after you typed in the whole word has nothing to do with you searching the word, but it's the general functionality for highlighting selected words. - The problem only appears when performing incremental search, not when selecting "Find All" in the power search - Highlighting is done right in the "Search and Replace" plugin for Kate - The relevant function is KateSearchBar::onIncPatternChanged(const QString &pattern). Calling at the end of this method KateSearchBar::findAll(inputRange, nullptr) highlights all occurences from cursor till EOF, but it's an ugly hack - I'm working on a cleaner solution.
https://git.reviewboard.kde.org/r/128592/
What you see there is the highlighting of the "selected" word. This is not the result of the search. To highlight all occurrences of the search word, there is "find all". One could argue that selected word highlighting should be turned of during search, but that would in my eyes be a bit strange, too. Or do you think that would make more sense?
(In reply to Christoph Cullmann from comment #3) > What you see there is the highlighting of the "selected" word. > This is not the result of the search. > To highlight all occurrences of the search word, there is "find all". > > One could argue that selected word highlighting should be turned of during > search, but that would in my eyes be a bit strange, too. > Or do you think that would make more sense? It's been a long time since I had the issue I reported, so my recollection is rather vague, and I haven't run into that issue again. I do remember that I found the behavior quite irritating. I think selected-word-highlighting should be turned off during search because the user is focusing on the search, and highlighting inconsistent with search results appears counter-intuitive. How about the following: when searching, turn off selected word highlighting, and always perform a "find all". Basically turn word highlighting into search result highlighting. In other words: there is already an efficient way to find and highlight words dynamically as the user is typing. Given that, I see no reason why the user should have to click "find all" to have all matches highlighted.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
FWIW i can confirm this issue, i run into it constantly. I think the behaviour that can be observed in QtCreator is much more useful - selecting something (e.g. with a mouse) results in all instances of the selected pattern being highlighted.
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
I am not sure what is the best behavior here. If somebody provides again some patch we can think about it.
Actually, master behaves already a lot better, like discussed below: It turns of the selected word highlighting. Therefore I consider this OK. If one wants further behavior changes, feel free to submit some merge request.