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
