Thanks for the feedback!  Some (hopefully) helpful responses, below.

>> Tim, I assume you're using the new list-filtering feature I put in
>> last year?  Just give any list of classes, categories, methods, etc.
>> focus and then start typing.
>
> Nope, because I had never heard of that and there isn't anything immediately cluing me in about it. That's a common issue with UI stuff - how to make it easy to use once you know of it whilst making it easy to find when you don't. Even though a visible search field would strictly speaking add clutter, it also adds that vital affordance.

Very true.  OTOH, typing in a list is something that is pretty much
universal in Windows, Ubuntu, very early Squeak and possibly other
environments.

You can see it was handled for the World Menu was the little balloon
that tells you you can do that.  Don't know how well that would work
for a list widget that newly gets focus (perhaps the balloon could
appear just for a few seconds and then disappear.. hm..).

>>  Is there something that could be done to
>> improve that function that would satisfy you?
>
> As a general idea for lists it's quite interesting and effective. I'm not sure the balance of when to stop adding new typing to the pattern or when to start a new pattern is worked out well enough; I found it a bit disconcerting that if I hesitated a fraction it started a new search. The background colour change as an indicator is nice.

Yes, for this function it's best know all of what you want to find
before starting to type it.  Usually 3 or 4 chars is enough and
Backspace takes you back to your prior place if it was a dead end
Might be nice if the delay could be dynamically adjusted based
TextEditor's notion of the typing-speed of the last user.

One thing I do like about it is the "direct control" feel; I don't
have to explicitly enter a "find mode"; nor any need to "Escape" out
of said mode.  Instead, I can just type something and, by no more than
the brief time elapsed (probably while I was consuming the results of
my typing), it's ready once again to navigate to next destination.

> The real problem is that the list I want to search in this scenario is one that doesn't strictly exist within the browser, so your code can't get me the answer I need.
>
>>
>> Also, have you considered setting the "alternativeBrowseIt"
>> preference?  Thanks to that preference, I haven't needed "find
>> class..." in a decade.
>>
>> Whereever I'm typing or, sometimes even in the Annotation pane, I'll
>> type a partial-match name of any class, press Command+B and the system
>> quickly(?) presents a list of matching classes (substring matching).
>> Even better, I'm now browsing the *code* model rather than the package
>> model, which is a much rarer need.
>
> Whilst that is very useful it still has a problem on a slow-ish machine in that it opens another browser window.

Ok, I didn't know whether the delay would be avoided by virtue of
opening Hierarchy browsers instead of full PackagePane browsers.  I
don't have a Pi.