Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Eclipse search plugin: providing a better, faster, more relevant Eclipse search."

Line 7: Line 7:
  
 
== About ==
 
== About ==
−
One of the most frequently used features of an IDE is find/replace and search features. Even the earliest source code editors focused on the importance of decreasing the search time and increasing relevance of the results. Even though the search facilities, especially find/replace features in Eclipse are adequate for most developers, there are still plenty of usability issues and enhancement requests arising in [https://bugs.eclipse.org/bugs/ Bugzilla]. Moreover, search performance in large projects seems inefficient without making use of indexing. Searching in all the files individually while trying to execute a search query on a project that contain a large amount of static files seems meaningless. Currently search feature in Eclipse Help component contains an indexing approach that works by indexing the help pages in the first query and then serving other queries from the index, improving the response time significantly. [http://lucene.apache.org/ Apache Lucene] is used for implementing this approach. Considering relevance of the search results, projects such as [http://www.opensolaris.org/os/project/opengrok/ OpenGrok] that offer a good source code search and cross-referencing engine exist.
+
One of the most frequently used features of an IDE is find/replace and search features. Even though the search facilities, especially find/replace features in Eclipse are adequate for most developers, there are still plenty of usability issues and enhancement requests arising in [https://bugs.eclipse.org/bugs/ Bugzilla]. This project aims to fix a few of these usability issues.
−
 
+
  
 
== Primary Goals ==
 
== Primary Goals ==
 +
 +
 +
====General Goal====
 +
 +
 +
* Unifying "Search" facilities so that there won't be 3 different search (and replace) functionalities in Eclipse
 +
 +
 +
====Specific Goals====
 +
 +
 +
[[Image:Progress.gif]]  Unifying Ctrl+F (Find/Replace dialog) and Ctrl+J (Incremental Search) by mostly behaving like Ctrl+J. Providing better UI utilization by not showing modal dialogs if the user doesn't request wider options. Summary of the idea: Firefox-style "Find" with enhancements. = a lightweight Find/Replace. Our main goal here is providing all functionality available in Ctrl+F with this lightweight Find/Replace. Here's the related Bugzilla entry: https://bugs.eclipse.org/bugs/show_bug.cgi?id=99294
 +
 +
 +
[[Image:Glass.gif]]      Providing "bridges" between Ctrl+F and Ctrl+H. This means carrying query information and search parameters back and forth between them when it's possible. --- To explain it better, it doesn't mean "sharing" input/settings, it is enabling the user to transfer "Find/Replace" input/settings to "Search" easily and extend his/her current search scope & query.
 +
 +
 +
[[Image:Glass.gif]]      Investigate better presentation of the search results in Ctrl+H ( adding an alternative view like Problems view - results in a table - might be a good idea to show result lines and numbers, paths etc. )
 +
 +
 +
 +
== Secondary Goals ==
  
 
====Solving usability issues====
 
====Solving usability issues====
 +
 +
A few of the following ideas are already a part of the specific project goals above.
 +
  
 
======Initial Ideas about Usability======
 
======Initial Ideas about Usability======
Line 78: Line 102:
 
'''10.''' Search in files: see matched lines
 
'''10.''' Search in files: see matched lines
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=72575
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=72575
−
 
−
 
−
====Integrating an indexing engine like Lucene or OpenGrok into Eclipse search====
 
−
 
−
======Initial Thoughts======
 
−
 
−
Here is an excerpt from [http://eclipse-soc.blogspot.com/2007/05/status-improving-eclipse-search.html my first blog entry] at [http://eclipse-soc.blogspot.com Eclipse SoC Blog]
 
−
 
−
 
−
"''I tried to keep myself focused on research at the beginning so I read about both Lucene and OpenGrok. I understood how OpenGrok achieved to be a great tool for source code browsing and cross-referencing. Since it makes use of Lucene, either way (if I use OpenGrok or not) Lucene is a building block of this project. I've read a few articles and browsed a few presentations about Lucene and I'm still trying to learn more about it.''
 
−
 
−
''I've been consistently asking questions to myself about index sizes and frequent updates to the index. As a basic solution, I thought of keeping a partitioned index ( e.g. A project having an index that is distributed to multiple Lucene indexes and these index files being accessed/changed when it's necessary. Shortly, we may call this partitioning the index file. ).''
 
−
 
−
 
−
''This absolutely has a tradeoff because of the cost of not using one index for the whole project. But, when a good number of partitions is selected, I think that the tradeoff will seem small. (I thought of computing the ideal number in the future, like the computation of ideal bucket size in file processing literature.)''
 
−
 
−
 
−
''I thought of this “partitioning” method because an Eclipse user can get very aggressive when we tell him that we can “linearize” the time to search his files but in order to do this, he has to keep like ~ 50 MB for the index in RAM. ( I've tried indexing different things and I think that this value is a good estimate for large projects. And by the way, a possible question is why do I have to keep things in RAM and do not write things to disc. One answer: dynamic nature of source codes and frequent updates. )''
 
−
 
−
 
−
''Partitioning approach gives us one advantage: we only have to index a part of the project when you are working on a set of files. Since the number of active editors is considerably less than the actual project size, it is an idea that can work. And since we can keep a relatively small index in RAM, indexes containing your active file set can be updated fast.''
 
−
 
−
 
−
''However, I still see other tradeoffs in this approach and it is just a start. By the way, I'm trying not to focus on algorithm-wise enhancements for now and I don't plan to implement this idea in my prototypes during the early days of coding. I plan to start coding by addressing usability enhancements first.''
 
−
 
−
 
−
''I think early search plugin prototypes will makes use of RAM – HDD data transition features of Lucene and just write the index to a file on the disc after a certain threshold.''"
 
−
 
−
 
−
== Secondary Goals ==
 
−
 
−
==== Enabling support for online code repositories ([http://www.google.com/codesearch Google Code Search], [http://www.koders.com/ Koders] etc.) ====
 
−
 
−
==== Enabling support for searching (indexed) CVS repositories ====
 
−
 
  
  

Revision as of 08:08, 12 July 2007

Student: Çağatay Çallı (IRC: kynes)

Mentor: Francois Granade (IRC: farialima)

This project is part of the Summer of Code 2007


About

One of the most frequently used features of an IDE is find/replace and search features. Even though the search facilities, especially find/replace features in Eclipse are adequate for most developers, there are still plenty of usability issues and enhancement requests arising in Bugzilla. This project aims to fix a few of these usability issues.

Primary Goals

General Goal

  • Unifying "Search" facilities so that there won't be 3 different search (and replace) functionalities in Eclipse


Specific Goals

Progress.gif Unifying Ctrl+F (Find/Replace dialog) and Ctrl+J (Incremental Search) by mostly behaving like Ctrl+J. Providing better UI utilization by not showing modal dialogs if the user doesn't request wider options. Summary of the idea: Firefox-style "Find" with enhancements. = a lightweight Find/Replace. Our main goal here is providing all functionality available in Ctrl+F with this lightweight Find/Replace. Here's the related Bugzilla entry: https://bugs.eclipse.org/bugs/show_bug.cgi?id=99294


Glass.gif Providing "bridges" between Ctrl+F and Ctrl+H. This means carrying query information and search parameters back and forth between them when it's possible. --- To explain it better, it doesn't mean "sharing" input/settings, it is enabling the user to transfer "Find/Replace" input/settings to "Search" easily and extend his/her current search scope & query.


Glass.gif Investigate better presentation of the search results in Ctrl+H ( adding an alternative view like Problems view - results in a table - might be a good idea to show result lines and numbers, paths etc. )


Secondary Goals

Solving usability issues

A few of the following ideas are already a part of the specific project goals above.


Initial Ideas about Usability

1 - Improve Ctrl-J search:

  • Ctrl-J : have Ctrl-V paste the current ring in it
  • Ctrl-J : if there's a selection, have a second Ctrl-J take this selection as search string
  • Ctrl-J followed by Ctl-R would switch to regex search
  • Ctrl-J to global search: transform a Ctrl-J to to a global search actually, drive all searches from the keyboard incremental search would be good: there should be a set of keyboard shortcuts on Ctrl-J to set up a complete search, and then execute it globally.

2 - Display search results. the view that displays the search results is very poor currently. Probably a tree view is not perfect. It should show the matches, for example. It should have more shortcuts...

3 - Improve the search dialog (Ctrl+H). More TBD

  • Would it make sense to always display the last search when opening the dialog ?
  • Not only should it be possible to remember the results of previous searches, but also be possible to refine (edit the criteria, etc) and re-run them

4 - Better multi-file search/replace (here, we are talking about Ctrl+H, "File Search" tab, and "Replace..." button, not Ctrl+F)

  • Usability: it is not clear how the search/replace works (what does it apply to ? What is the "Stale matches" dialog ?
  • User Interface quality: accessing search/replace is a modal dialog (modal dialog are never very good) that is accessed from another modal dialog (idem). Which means that the user need to complete multiple step, with complex UI, to access a functionality that's a basic Editor functionality. At least, for example, "Search/Replace" should appear in the "Search" menu, as usual most tools
  • selective (based on language elements...)
Bugzilla Reports Related with Usability

1. find/replace search should have a tick-box for "ignore comments" (enhancement request) bug 161398

2. Show as package tree bug 160481 (enhancement request)

3. Store Previous Searches for Startup (enhancement request) bug 169252

4. Search dialog "Java Search" Scope should include Hierarchy (WONTFIX bug) bug 110252

5. New text search shown line not a great help (LATER) bug 127672 (This bug is waiting for applying styles on a tree item.)

6. Result in Table (LATER) bug 129185

These two are related:

7. Search shows duplicate results in nested projects (LATER) bug 144959

8. Resource exclusion filters bug 84988

(read together with: bug 144959 - about duplicate results for nested folder structures)

9. Search Enhancements bug 108223

10. Search in files: see matched lines https://bugs.eclipse.org/bugs/show_bug.cgi?id=72575


Getting and Building the Source Code

I've committed my work as a patch to "soc-search" module in "eclipse-incub". It's very primitive right now but you can checkout anytime and see what I'm doing.

Host: eclipse-incub.cvs.sourceforge.net

Repository path: /cvsroot/eclipse-incub

Module name: soc-search


To build this project, do the following in order:

1. Checkout these items from Eclipse HEAD:

  • org.eclipse.jface
  • org.eclipse.jface.text
  • org.eclipse.ui.workbench
  • org.eclipse.ui.workbench.texteditor


2. Choose a patch from "findreplace" folder and apply it to given packages.

  • findreplace-editorbar.diff ( apply to org.eclipse.ui.workbench ): Patches "org.eclipse.ui.workbench" in order to add a composite containing a Label and a Text widget, to the bottom of the editor.
  • findreplace-statusbar.diff ( apply to org.eclipse.ui.workbench.texteditor ): Patches "org.eclipse.ui.workbench.texteditor" in order to replace "Incremental Find"s Label widget with a Text widget. This Text widget is capable of accepting cut/copy/paste events.


That should be enough. You can test it by running corresponding project as an Eclipse application.


Update Site

You can also install the project using Eclipse "Software Update". The update site address is as follows:

http://user.ceng.metu.edu.tr/~e1394824/QuickFindUpdateSite/site.xml

Retrieved from "https://wiki.eclipse.org/index.php?title=Eclipse_search_plugin:_providing_a_better,_faster,_more_relevant_Eclipse_search.&oldid=42651"

Back to the top