GNOME Bugzilla – Bug 545389
Create a "Find in files dialog"
Last modified: 2012-02-12 12:30:45 UTC
Currently the search plugin searches some kind of main loop hack to avoid UI lock-up when search in multiple files (or putting the results in the find pane). The goal is to use multi-threading instead because currently the UI may lock-up for several seconds. Anjuta already has some framework for this (anjuta-command.[ch]).
Created attachment 128378 [details] [review] patch for this bug In this patch, I split search_and_replace function into search_update_ui and SearchGetNext class (parent AnjutaAsyncCommand).
Failded to apply this patch, $ patch -p0 --dry-run < 545389.patch patching file plugins/search/search-get-next.c patching file plugins/search/search-get-next.h patching file plugins/search/search-replace.c Hunk #2 FAILED at 275. Hunk #3 FAILED at 434. 2 out of 3 hunks FAILED -- saving rejects to file plugins/search/search-replace.c.rej patching file plugins/search/search-replace_backend.c Hunk #1 succeeded at 135 (offset -4 lines). Hunk #2 succeeded at 462 (offset -72 lines). patching file plugins/search/Makefile.am Hunk #1 succeeded at 45 (offset 1 line). patching file plugins/search/search-replace_backend.h Hunk #1 succeeded at 209 (offset -6 lines). Could you please update your patch against the svn head, or upload search-replace.c?
Any chance to get this update for git master? That would be really, really nice to have!
Would be really nice if someone could update the patch!
I have looked at this patch. I have applied it in the current master branch but I think it would be better to postpone it to the next release. The 2 failing parts are rather big and correspond to code where several fixes have been done afterward, including crash fix. I have tried to reapply all the fixes but it's quite easy to miss one. As search is an important function, I think it's better to apply it after the release so we will have more time to check that it's working fine. I will try to fix it and I will attach it here. I think I can do this before the end of the week.
There is more work than just updating the patch against the latest sources. The patch is not working. There is at least one bug because search_update_ui which is responsible for updating the UI and can be called several times, is changing the state of the search. It toggles a variables named interactive which define if a replacement should done or not. The whole code in general is not very nice neither and the search dialog is too complex. Perhaps it would be better to rewrite the whole dialog to clean all this stuff ?
> The whole code in general is not very nice neither and the search dialog is too > complex. Perhaps it would be better to rewrite the whole dialog to clean all > this stuff ? Yes, of course redoing the dialog (discussing with usability guys, probably splitting this into a global search and a file search dialog, see also some other bugs in the search plugin) would be great. Let's postpone this to 3.0
Created attachment 162235 [details] Updated patch from Maxim, but still not working This is a part of the work that I have done on Maxim patch, the last time I work on it, just before the release 2.30. This patch can be applied but it is still crashing Anjuta. I have stopped working on it as I think we need to change the interface of the search dialog and UI changes was not possible at that time.
*** Bug 628942 has been marked as a duplicate of this bug. ***
Changing this bug to reflect that we don't have "Find in files" currently.
*** Bug 647808 has been marked as a duplicate of this bug. ***
*** Bug 658234 has been marked as a duplicate of this bug. ***
Done: http://git.gnome.org/browse/anjuta/commit/?id=dae1d490ea45d385fc62eac2c6d04894690a84c3 Test it, break it, propose better ui... This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.