GTSpotter is moldable. The default Pharo 5.0 image comes out-of-the-box with 122 distinct types of search processors. Understanding and controlling these processors is key for using Spotter to its full extent.
The first thing about it is to learn what these extensions mean. Each of these extensions is defined in a method, and the average size of such a method is 8.5 lines of code (including the header and the annotation line). In most cases, the code of the method is the best description of what they do.
Let’s take an example:
TClass>>spotterMethodsFor: aStep <spotterOrder: 10> aStep listProcessor title: 'Instance methods'; allCandidates: [ self methods ]; itemName: [ :method | method selector ]; filter: GTFilterSubstring
As this method is defined in
TClass, the search processor will get activated when Spotter will get to a class object. In this case, there will appear a search category that:
method selectoras textual description for the item, and
Most Spotter extensions look like this. Once you know how to read one, you will understand most of the others.
While each search processor can be small and easy to understand in isolation, understanding the overall landscape of all extensions is another problem on its own. To make it easier to grasp what exists, there are several places to look at.
First, the Spotter help lists all extensions available in the image split by name of the corresponding classes. This is a useful entry point to get a quick overview.
However, if you look for live examples you can simply inspect GTSpotter, and you will get the list of all extensions.
These two tools can allow you to keep track of extensions. Keep in mind that the default start object when opening Spotter is an instance of
GTSpotter. Thus, to look only for the top level extensions, we can inspect this expression:
GTSpotter spotterExtendingMethods select: [ :each | each methodClass = GTSpotter ]
In the Moose image, this returns 25 extensions. But, what if you do not want all these extensions?
For this you can turn to the Settings Browser. Every extension in the image gets associated dynamically a setting element. Unchecking the setting will disable the corresponding extension. These settings can also be stored and loaded for use in further images like any other settings.
This mechanism can also be useful if you want to change the way a search works. For example, the top search for classes happens based on a substring filter strategy:
GTSpotter>>spotterForClassesFor: aStep <spotterOrder: 10> aStep listProcessor allCandidates: [ Smalltalk allClassesAndTraits ]; title: 'Classes'; filter: GTFilterSubstring; itemIcon: #systemIcon; keyBinding: $b meta; wantsToDisplayOnEmptyQuery: false
If you want to use a regular expression instead, you disable the default class search in the Settings Browser, and add another extension method in your own package with a regular expression filter:
GTSpotter>>mySpotterForClassesFor: aStep <spotterOrder: 10> aStep listProcessor allCandidates: [ Smalltalk allClassesAndTraits ]; title: 'Classes'; filter: GTFilterRegex; itemIcon: #systemIcon; keyBinding: $b meta; wantsToDisplayOnEmptyQuery: false
Done. Now, you can search for classes using regular expressions. In the same way you can manage all other extensions.