Hi Chris, In fact, no, I didn't realise that all of that had been argued over, nor that the patch was finished. The thread I posted on didn't mention anything about some of those points, nor that it was already done!
Also I don't think my comments were resurrecting an old thread considering that your previous post was only about 32 hours earlier than mine. Regards David G On 20/12/15 13:56, Chris Pavlina wrote: > You do realize we've already argued over pretty much all the points you > made, and _finished_ the patch already? > > On Sun, Dec 20, 2015 at 01:17:07PM +0800, David Godfrey wrote: >> Wow, 2 posts from me in the same day! >> That is unprecedented ;-) >> >> Comments inline..... >> >> On 19/12/15 04:56, Wayne Stambaugh wrote: >> >> On 12/18/2015 2:22 PM, Chris Pavlina wrote: >> >> Thanks, and I don't mean to sound grouchy about it. I don't want to try >> to be a backseat driver and start insisting we do things My Way, or >> anything like that. It's just that my proposed change is really quick >> and simple, and would scratch a massive itch of mine - I'd definitely >> not object to adding even more stuff, but I've been really limited on >> time lately... fuzzy matching sounds kinda interesting, and it'd be cool >> to see it added. It just wouldn't do anything for the reason I wanted to >> add wildcard matching, and as much as I wish I had time to spend coding >> cool things that _don't_ help me... I don't have any. :( >> >> You're allowed sound grouchy! You're the one who's implementing it so >> you get the lion's share of the say. That's not to say other devs input >> isn't useful but at the end of the day, you're one writing the code. >> Here is my 2 cents. From an advanced users point of view, wildcard and >> regex searching is great so I'm all for it. However, how many users >> really know how to use regex or even simple wildcard searches? >> Experience has taught me that very few actually do. In fact, the only >> users I know that know how to use them are developers. We (myself >> included) should always keep that in mind when writing code. One simple >> option might to create and abstract pattern matching base class >> (EDA_PATTERN_MATCH) and only implement a wildcard and/or regex >> implementation. That way in the future, if someone feels really >> ambitious, they can create any number of fancy pattern matching >> algorithms without having to rewrite the code that utilizes it. >> >> >> Can I suggest using the time honoured method of a set of radio buttons (or >> dropdown list) allowing selection of what type search you want to perform. >> mcedit (midnight commander editor) has a good example of this in it's text >> user interface.... >> >> I think in the long run we may want to support >> >> • Normal >> unless enclosed in /'s or ~'s it is a simple substring search with >> implied wild cards at start and end of the pattern >> • Wildcard >> • Regex >> • Fuzzy / Smart search >> >> There should be a help popup associated with a small ? button alongside >> each option. >> >> I also think we should change our existing default search type to include >> the implied wildcards at start and end of the pattern. >> This would go a long way to helping non technical (from a programming >> perspective) users find the parts they want. >> We could also assume that (if the selected type is "normal") >> >> • if the pattern is enclosed in a pair of /'s it is a regex >> • if the pattern is enclosed in a pair of ~'s it is a fuzzy search (once >> implemented) >> • if it is not a regex or fuzzy search and contains a wildcard [*?] then >> it is a simple wildcard match >> >> Use of / or ~ to identify a regex or fuzzy pattern should not be required, >> as the user could have overridden this by making a manual selection of the >> type. >> >> By requiring that a regex or fuzzy pattern be enclosed in / or ~ chars for >> auto type selection (if entered in the search box) it allows any pattern >> type to contain these characters even as the first character of the >> pattern by simply selecting the pattern type from the radio or dropdown >> list. >> >> This is not all of the solution, but should allow extra capabilities to be >> added during the life of the software supporting both normal users and >> users with more knowledge. >> Also it helps to educate users that there are other ways of searching that >> may be more useful. >> >> The tilde (~) is often used to indicate approximation (in the world >> outside programming) hence the suggestion it is used to denote a fuzzy >> search. >> This does conflict with a common programming use of the tilde to indicate >> a regex, but as regexes are often (think grep and awk) wrapped in /'s it >> is a good compromise. >> >> So, if Wayne &c don't object to adding a simple wildcard search, I'd >> happily spend a few hours on that. But if we decide we want something >> more complicated - I won't complain and object, but I don't really have >> much time to work on it either. >> >> No objection but please consider my base pattern matching class and >> wherever you use pattern matching, that code should take a reference or >> pointer to the base pattern matching class. >> >> Completely agree with this. >> The class should, if possible, include a link to one or more graphical >> objects that provide the search type options. >> If there is more than one graphical object only one should be required per >> search window, any extras should be replacements that offer a different >> layout or group of visible features. These would be used where a feature >> doesn't make sense such as a case sensitive search on data that is always >> case insensitive (eg: net names if config says they are case insensitive) >> . >> >> >> On Fri, Dec 18, 2015 at 01:57:16PM -0500, Jon Evans wrote: >> >> Hi Chris, thanks for the feedback. I certainly don't expect you to waste >> your time implementing something that you don't want/need! I think if you >> end up implementing wildcard match it will be a good starting point for >> adding fuzzy matching later if someone wants to take that on (maybe even I >> would!), at which point we can try it out and see if anyone else besides me >> thinks it's a better way to search. >> >> BR, >> Jon >> >> On Fri, Dec 18, 2015 at 1:51 PM, Chris Pavlina [1]<[email protected]> >> wrote: >> >> >> This is just going to clutter up the results with a bunch of annoying >> false positives. If you want it, fine, but I'm not going to waste my own >> limited time on it. All I want is a simple, predictable pattern match. >> On Dec 18, 2015 13:32, "Mark Roszko" [2]<[email protected]> wrote: >> >> >> We can probably implement it ourselves as a wx based control, >> >> The JS implementation is only 100 lines. >> [3]https://github.com/mattyork/fuzzy/blob/master/lib/fuzzy.js >> >> You don't need a C++ library or anything >> >> >> A problem I can see with fuzzy searches is how to set the boundaries that >> define where extra characters can be present. >> A common fuzzy search that we would use (eg: 74123 ) may convert to a >> wildcard search that looks like.... >> *74*123* >> We would probably not want it to return results that match >> *7*4*1*2*3* >> which is what the simplest implementation of a fuzzy search would return >> >> For some fuzzy patterns it will be fairly obvious what the intended >> boundaries are (like the 74123 example) >> for others we can imply the boundaries as being at the transition between >> character types, >> 74hc123 => *74*hc*123* + *74*123* + *hc*123* >> As you can see it gets complicated fast for our use case.... >> Converting that same fuzzy search (74hc123) to a regex may make more >> sense. >> 74hc123 => 7+.*4+.*h+.*c+.*1+.*2+.*3+.* >> (the above regex is based on the definition found in linux's (man 7 regex) >> As this shows we can expect to get a lot of unwanted matches unless we >> recognize some expected patterns and produce special cases for each one. >> The results of the special cases should always be presented first, with >> the full (anything can be between each character) results presented last. >> >> This is an oversimplification of the problems we can expect to face with a >> user-friendly implementation of a fuzzy search. >> Regardless of anything else, a good regex implementation would be >> desirable first as a fuzzy search should just be a conversion from the >> input pattern to a single or group of regex's. >> Any other way is probably duplicating much of the regex code anyway. >> >> Regards >> David G >> >> References >> >> Visible links >> 1. mailto:[email protected] >> 2. mailto:[email protected] >> 3. https://github.com/mattyork/fuzzy/blob/master/lib/fuzzy.js > > >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
