As far as I can tell, it’s actually .Contains, but it’s inconsistent (well, kind of).
You can search within the tree with a mix of qualifying and direct match of a space-separated string, which is IMHO an odd by-product of a decision to humanize activity names.
What I mean is - you can navigate the tree by qualifying the namespace (or classification in some cases), f.e. searching for “Programming.Data” will show only what’s under Programming -> DataTable (since only this matches the string directly). This leads to conclusion that you can search by qualified names, which is incorrect - for actual activity names, you need a space before all capital letters.
This produces weird valid searches, f.e. “DataTable.Add Data Column”. From consistency perspective, you’d expect “DataTable.AddDataColumn” to also work, as well as any combination of those 2 conventions, while it needs to be an exact match to what is displayed, not to what is the actual name of it.
IMHO Hamming (or more probably Levehnstein, since length can differ) distance is not even needed - typos are a user mistake and it would slow down search functionality.
Just make it tolerant to white space (both ways) and as a second pass, if user query contains spaces, do a contains all words search, so as @Bogdan_Popescu said, ‘build table’ should return Build Data Table, but in my opinion ‘buildtable’ should still fail (as it’s neither a word combination or a part of a proper activity name).
Sidenote - I can’t count how many times I’ve typed ‘add row’ to not get anything displayed…
Other opinions would also be appreciated, maybe from some non-programmers as to what they expect from the search functionality.