This is super cool! But now I need to lookup: “How to make your own Spotter engine(whatever you call the thing)” ;) Cheers! Uko

I’ve already seen the extending method. I’m doing is “core” processor like spotterStfxFor:. And it’s a bit hard to combine all the pieces into one vision. But slowly I’m getting there. Uko

Thank you, that’s helpful. But I’m a bit confused about filters. Also, as far as I understand, each extension is calculated asyncrously and added to the whole result when done. But is it possible to add items one by one as they are calculated? (I know that this sounds as a bad use case). Uko

Hi, Ok, this is more tricky, but it is supported :). Actually this is one of the really cool things about Spotter. For this we have #filter:item:. Look at the senders to find examples in the image. For example: PragmaType>>spotterSendersFor: aStep <spotterOrder: 50> ^ aStep listProcessor title: 'Senders'; filter: GTFilterSubstring item: [ :filter :context | self keyword senders do: [ :sender | filter value: sender compiledMethod ] ] or: GTSpotter>>spotterForReferencesFor: aStep <spotterOrder: 32> aStep listProcessor title: 'References'; filter: GTNullFilter item: [ :filter :context | context textTrimmed asClassIfPresent: [ :class | SystemNavigation default allReferencesTo: class binding do: filter ] ]; keyBinding: $n shift meta; itemName: [ :method | method gtDisplayString ] so, the block is being passed a filter which actually behaves like a block :). So, you can pass it to whatever traversal you have, and this will stream the results back to Spotter. I find this so cool that I cannot describe it :). Let me know if this helps. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

They sure are short :). Indeed finished before I had read the video title. It was useful once I worked it out. Thanks Doru. cheers -ben On Thu, Feb 25, 2016 at 4:38 AM, Tudor Girba &lt;tudor(a)tudorgirba.com&gt; wrote: