The toolbar contains further options for narrowing your search and for organizing the search results.
The grouping options allow you to add intermediate layers to the results tree. You can choose to add nodes grouping the search results by the query category that found the search result, project or JAR, the package, or the type. If you wish, you can turn on more than one, or even all, of these grouping options. If you don’t group by the query category, a single top level node is added to the result node, showing which search was performed. Each grouping option can be toggled by its own keyboard shortcut. Note that the leaf options allow you to specify how the lowest levels of the tree are organized.
You can configure Code Search to aggregate similar expression results within the results tree. This causes similar results to be grouped together by displaying only the relevant part of each result’s name, thus allowing you to more quickly identify common patterns. You can configure what constitutes a similar result using the aggregation options.
Enabled by default, you can toggle result aggregation by clicking on the icon. You can fine tune result aggregation further by changing options in the drop-down menu. The purpose of all aggregation options is the same: Removing or canonicalizing information that is superfluous in your current context, so that search results that only differ in minor points are grouped together.
Aggregation options are grouped into three sections:
When searching for expressions, it may not be relevant what precise argument was used for a method call.
Argument aggregation allows you to remove that information using any of these settings:
- Arguments as Actual Types
Replaces any argument expression with the name of its type.
- Arguments as Declared Types
Replaces any argument expression with the name of the declared argument type.
- Arguments as '…'
Replaces any argument with '…'. Method calls without arguments also have '…' inserted. This option results in overloaded method calls being aggregated.
When searching for expressions, it may not be relevant what precise receiver of a method call was used.
Receiver aggregation allows you to group expressions with similar receivers together using these settings:
- Receivers as Actual Types
Replaces a receiver with the name of its type.
- Receivers as Declared Types
Replaces a receiver with the name of the type declaring the method.
Additional options allow you to further configure aggregation:
- Generics as '<>'
Remove any generic type information from expressions.
- Literal Values as Types
Replaces any literal values with the name of their type.
- Local Variables as Actual Types
Replaces the names of local variables with the name of their type.
- Qualified Static Accesses
If not already the case, qualifies any static access.
- Qualified 'this' Accesses
If not already the case, makes any member access explicit by prepending the expression with this..
The filter options allow you to target your results. For example, you can choose to filter non-static results, or you can filter results originating from either test or production code. You can also choose to filter out the projects of your own workspace, the dependencies of your workspace, or JARs stored on a remote server.
The commonly used options to filter non-public or non-static results are available right in the toolbar.
Additional options can be used to filter results based on the code’s location, or whether or not it is test specific code.
With linked mode activated, Code Search performs a search every time the cursor location changes in the Java editor.
By default the Code Search view will automatically choose the arrangement of its components that best makes use of the available space. Using the layout options you can override this so as to always use either a horizontal layout (with the results tree to the left of the preview) or a vertical layout (with the results tree above the preview). You can also remove the preview altogether by selecting Results Tree Only, allowing you to focus on the results tree.
Using the leaf options you can specify how the lowest levels of the results tree are organized.
By default the leaf nodes of the tree indicate the location where the search result can be found (for example the method or class in which it appears). The leaves are then grouped according to the code defining that result.
Alternatively, you can choose to reverse this grouping so that the leaves display the code, but are grouped by their location. This is useful to quickly find all locations where a particular method is called, regardless of the exact expressions that perform the calls.
The leaf options menu allows you to either select the desired option directly or toggle between them.
Alternatively, you can perform toggle between leaf options using the keyboard shortcut
CTRL + SHIFT + L, or
CMD + SHIFT + L on macOS.