Version: (using Devel) Compiler: gcc version 4.3.1 (Gentoo 4.3.1 p1.0) OS: Other Using kate in kde 3.5 I got used to search the same term in more documents, without having to digit the search term multiple times. Pressing "F3" key on whatever document did searched for the last term used. The behaviour introduced in kde4, may be useful but most of the times a shared search history is just enough and possibly nicer ;) Having a config option (possibly with default to the old behaviour) would be great.
What can be done to help development ?
We currently treat searching as something view-specific, not view-shared. I don't see a way to fit your request in with this.
(In reply to comment #2) > We currently treat searching as something view-specific, not view-shared. I > don't see a way to fit your request in with this. > It's a pity, even vim share last search between documents, it's handy in many cases. Thanks for all the fish anyway.
@Sebastian Well, but if it worked in KDE 3.5, why shouldn't it work now? At least technically it shouldn't be too far away. I've noticed the same behavior in KDevelop4, and it's really annoying. @Francesco: If you want to help, grab the kdelibs sources and start hacking the kdelibs/kate subdirectory. :-)
(In reply to comment #4) > @Sebastian Well, but if it worked in KDE 3.5, why shouldn't it work now? At > least technically it shouldn't be too far away. I've noticed the same behavior > in KDevelop4, and it's really annoying. It's a conceptual problem: Let's say you have two views open both showing a search bar. If you search for "foo" in the first window, "bar" in the second, why should the first search for "bar" then when you go back and hit F3? I'm not pro implementing this unless we find a consistent way. Do you see any?
Well, but that only plays a role when the bar is actually visible. So what about this: - Globally remember the last search. - Whenever opening a new search bar, initialize it with the globally stored last search -Whenever pushing F3, test if a search-bar is open in this document. If not, use the globally stored last search, else use the search from the open search bar. That would approximately be the behavior I would implicitly expect. You would always know what's happening. Either you see the search-bar, or you search what you've last searched.
Thanks, doesn't sound too bad :-) Before I start to try: What do the main KatePart devs think about it? Is this wanted or not?
In case I'm still a main kate dev: I think hvaing global search is a very good idea. As for Davids comment #6, I often want to use F3 without the searchbar open. My own notes contain a very old idea of letting the user search the current, all or a selection of documents.
Created attachment 27597 [details] Beta patch to do what David Nolden described in comment #6 Please let me know how it works. I don't feel it's ready for check-in, yet.
(In reply to comment #9) > Created an attachment (id=27597) [details] > Beta patch to do what David Nolden described in comment #6 > > Please let me know how it works. I don't feel it's ready for check-in, yet. > > Globally remember the last search. work for me > Whenever opening a new search bar, initialize it with the globally stored last search ... does not, or I've not understud this >..Whenever pushing F3, test if a search-bar is open in this document. If not, use the globally stored last search, else use the search from the open search bar... work for me Disclaimer: I've tested this in a ibrid environment, ie: building patched kdelibs in $HOME/tmp/ and then running system kate as: LD_LIBRARY_PATH=$HOME/tmp/lib /usr/kde/svn/bin/kate Rather orrible what's the minimal steps needed to have a complete build of kate?
(In reply to comment #10) > > Whenever opening a new search bar, initialize it with the globally stored last search ... > does not, or I've not understud this Right. It's a mix of I-forgot-about-it and is-this-the-right-thing thing. If I implement this it means whenever I close a search bar it's state gets lost. Please make we see why that's a good idea. > Rather orrible what's the minimal steps needed to have a complete build of > kate? You need kdelibs and kdesdk and their dependencies. This page got me started: http://techbase.kde.org/Getting_Started/Build/KDE4 I guess I misunderstood your question, if it's not what you need.
*** Bug 172193 has been marked as a duplicate of this bug. ***
I also believe comment #6 is a good approach, didn't try the patch yet, but the code looks as if it is doing what comment #6 says ;) Reinitializing and initializing is maybe another topic - initialize with selected text, if single line selection (good heuristic) - otherwise: check whether there is text in the last search - otherwise: leave empty
What ever happened with this? It doesn't seem to the behavior now if I am reading it correctly.
This should be the behavior in KDE 4.6. Please someone confirm by following http://kate-editor.org/get-it/ and build Kate from the sources.
I just tried in KDE 4.6, but I still can't search for a string in one document, move to the next and find that string with F3, I have to reopen the search bar, and re-enter the search term.
Any progress with "comment #6" idea? Current dev version still lacks this feature and per-view search strings are (at least) not very useful :( commit 45ac44478c1f7f50d89f0a93aff27b099a9273df Date: Fri Mar 30 16:51:27 2012 +0200
;)
*** Bug 203969 has been marked as a duplicate of this bug. ***
This is a valid wish.
I've used many advanced editors over the years and this is the only one I've ever seen that makes searches per-view like this. I really miss being able to take the same search (and replace) from tab to tab effortlessly. However, I find *sometimes* the per-view search state is actually useful. It's really a usecase thing. Sometimes (most of the time!) your find/replace is something you want to do several documents you have open. But now and then you have a usecase like this: I want to repeatedly find some code string in a handful of files I have open, to make possibly make some changes at each point. But then in the middle of doing this, for one of the changes I need to make, I need some bit of text from one of my open files, and I need to do a find with some different string to locate the right spot in this other file I need to copy from. And maybe I need to do that repeatly. So in this case, it's really awesome to have different (persisted) find state in one view than in the others. So the best thing, IMO, would to be able to select between these two behaviors, or perhaps there is some different way of conceptualizing it which lends to covering both of them?
BTW I'd like to note that the title of this bug is a little confusing. At first I took it to be about the scope of the find / replace operation. I suspect if the title were cleared you'd have more votes and less duplicates. I would propose "Use same values in find / replace dialog across all windows"
And isn't Bug 242037 a duplicate of this also?
*** Bug 242037 has been marked as a duplicate of this bug. ***
Dear user, this wish list item is now closed, as it wasn't touched in the last two years and no contributor stepped up to implement it. The Kate/KTextEditor team is very small and we can just try to keep up with fixing bugs. Therefore wishs that show no activity for two years or more will be closed from now on to keep at least a bit overview about 'current' wishs of the users. If you want your feature to be implemented, please step up to provide some patch for it. If you think it is really needed, you can reopen your request, but keep in mind, if no new good arguments are made and no people get attracted to help out to implement it, it will expire in two years again. We have a nice website kate-editor.org that provides all the information needed to contribute, please make use of it. For highlighting improvements our user manual shows how to write syntax definition files. Greetings Christoph