Tuller/LibItemSearch-1.0 — pull request #4 by Jaliborc (2011-10-18 13:48:27+00:00)
Title: Making it Smarter: Less Syntax, More Searching

A while ago, a friend of mine figured out that typing "Epic" in the search box didn't do anything. After bugging me out like hell for it, I've finally taken some time to look into the issue. I simply tried to make the library smarter and, when I could without changing much, faster. I hope you like the changes. If you don't, well, close the pull request :P

== Less Syntax, Smarter Searching
Let's face it. Most users don't know the syntax, don't even know it exists, and, if, they do, they won't bother reading it. And you know what? They're right. Searching is suppose to save you time and brain-work, not more memorizing and learning how to search for items. Google, Yahoo, and whatever internet crawler you might use almost don't have any kind of syntax.

So, my objective was simple: to make the library to "know" what search types to use without the having telling it, and to be able to use more than one search types at the same time. For example:
1) "Trade" will accept any "Trade Goods" items or any item with "Trade" in its name
2) "40" will accept any item with "40" in its name or iLvl 40
3) "Legen" will accept any "Legendary" item or with "Legen" in it's name
4) "> Rar" will search for items with quality above "Rare"
5) "> 40" will search for items with iLvl above 40
6) "a" is to short, won't search for anything

Having this said, the internal changes aren't that much. Here's the highlights:
1) Previously, the library tried to use one of the search types and, if none of them corresponded to the syntax, used a "default" conduction. Now the library checks for each search type if it can be used. If any of them apply and match the item, it won't be filtered out.
2) Only the most intense searching types (tooltip search and equipSet) still require to be specified by the user to take effect. There many be ways to workaround both of them, tough.
3) Replaced string.match for string.find whenever possible. It's supposedly faster, as it does not create and allocate the resulting substring in memory.

P.S: I've renamed some of the local variables. If you would rather have them the other way, change them back. It's not much of a issue, just made it easier for me when coding.