When incrementally searching using the find bar, the info message appears in the middle of the text area, sometimes hiding the found result. Steps to reproduce: 1) Open a large text file 2) Search a word that occurs in the middle of a line using the find bar 3) Hit Enter (find next) until the search continues from top Result: The info message appears in the middle, covering the middle of the centered search result. Additionally it stays there for a long time, and blocks/queues other info messages. Expected result: Info messages appear instantly at the top/bottom next to the scroll bar with the text "Continuing search from top/bottom", like it did until some days ago. This feature is annoying because: I need to jump through long dataset summary files, where many datasets look very similar. One dataset is lokated some pages below the other, and I want to compare them. I use the search bar to jump between them. Now, this centered info message doesn't change and hides the dataset number, so I don't know where I am just now. Unfortunately I couldn't downgrade katepart via aptitude, so I don't know which module causes the problem. But I think it's katepart.
@Alex: Any ideas on how to improve this? :/ Whatever we do, someone always complains.
I thought it was fine before in the corner, but now I have the same issue of obscured text. Probably the middle of the window is the worst place it could be in terms of possible text obfuscation. To me, it makes sense to put it somewhere at the bottom near the search bar, and I would recommend the bottom right since (i) that is the default location of notifications in KDE, and (ii) there is more likely to be no text there than on the left (unless your language reads from right-to-left).
I was just going to report this too and observe that the message was fine where it was. Consider this: searching through a body of text is an inherently visual activity where you look at your screen attentively. Even if you look at the centre of your editing view (where the search results are (almost) always shown) your peripheral vision will still pick up a message that flashes at the top or bottom of that view. It will be pretty obvious why if that happens when you just hit the key to jump to the next search hit. The easiest way out of this regression would be to make the location configurable. Some will still complain, but at least we can chose whatever is least annoying. Alternatively, why not mark the startpoint of a search in the left margin, or by making the location stand out otherwise in a way that doesn't affect readability? Even a brief view background flash would do the trick for me. FWIW, 2s is really long for something to remain posted right in front of your eyes, hiding your text. The offending commit: cc8b2208
(In reply to RJVB from comment #3) > The offending commit: cc8b2208 That's what I was searching for for a long time, before I opened this report. (I did grep -r "Search Wrapped", but without success.) It shouldn't be difficult to change the line > 625: m_wrappedMessage->setPosition(KTextEditor::Message::CenterInView); to something configurable. (I never did something like that.) D9394 (cc8b2208) doesn't provide any references (bug/whishlist reports, etc.), but says that the corner messages weren't prominent enough. Well, maybe they weren't for some users. But I think, users who use the Find&Replace Bar (maybe with regular expressions), instead of the Find Bar, know very well what's going on, so the "more prominent" messages are not needed. Would it be OK to change back to the corner messages at least for the Find&Replace Bar?
Created attachment 116422 [details] patch to revert to simplified previous behaviour I've patched the code for myself, back to using the Information colour (more appropriate IMHO, definitely for my colour scheme) and just pop the message at BottomInView. The previous implementation showed the message at the top or bottom depending on how the search wrapped, but that's needlessly complicated IMHO. We know in what direction we were searching, and I don't see the added value of knowing (confirming) in what sense the search wrapped (beyond the icon already displayed in the message). Those are easy changes for anyone to apply, if they feel like building a framework from source (and installing all required dependencies to do that).
Created attachment 116423 [details] snapshot (I also have a personal patch to make KMessage's less gaudy :) )
With this patch the messages still queue, when you jump forward and back fast enough. However, in my opinion the messages may do anything, unless they are in the middle of the screen... (In reply to RJVB from comment #3) > Even a brief view background flash would do the trick for me. Hmm, that's like screen flickering. I think, I wouldn't like that.
I think the queuing isn't new. Shouldn't really be a problem because how often do you let the search wrap ("jump back and forth") under normal use? I agree that a view flash is like the screen flickering and thus not very appealing - if you fill the entire screen with that view. But again it would be only once under normal use. Anyway, we'll see what the devs come up with.
Under normal use: very rarely. It was very convenient for these database summary files, to compare the first and the last entry of the same thing. I didn't install updates on that machine, to keep the corner messages. Split view would have been another possible method, of course.
@René: Could you post the patch on Phabricator?
Git commit ac35dba359887e1feb881d01ec15db32116943a6 by Christoph Cullmann, on behalf of René J.V. Bertin. Committed on 04/03/2019 at 18:45. Pushed by cullmann into branch 'master'. Restore the search wrapped message to its former type and position. Summary: This fixes issue 398731 by restoring the "search wrapped" info message to its former type and position. Test Plan: works as intended (= as before #cc8b2208) Reviewers: #ktexteditor, dhaumann Reviewed By: #ktexteditor, dhaumann Subscribers: dhaumann, neundorf, loh.tar, ngraham, kwrite-devel, kde-frameworks-devel Tags: #ktexteditor, #kate, #frameworks Differential Revision: https://phabricator.kde.org/D19416 M +2 -2 src/search/katesearchbar.cpp https://commits.kde.org/ktexteditor/ac35dba359887e1feb881d01ec15db32116943a6
Created attachment 120255 [details] The new position of the search wrapped popup messages (In reply to RJVB from comment #8) > I think the queuing isn't new. Shouldn't really be a problem because how > often do you let the search wrap ("jump back and forth") under normal use? > [...] Actually, I do that very often now. Use case is to compare usages of Okular class members. (They are often undocumented and I want to know why e. g. a signal is emitted.) (In reply to Michael D from comment #2) > [...] To me, it makes sense to put it somewhere at the bottom > near the search bar, [...] It’s not necessarily near the search bar, but it looks fine now. See attachment. Thanks for fixing this.
*** Bug 410725 has been marked as a duplicate of this bug. ***