|
Wow, 2 posts from me in the same day! That is unprecedented ;-) Comments inline..... On 19/12/15 04:56, Wayne Stambaugh
wrote:
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.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. 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
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.
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. The tilde (~) is often used to indicate approximation (in
the world outside programming) hence the suggestion it is used
to denote a fuzzy search. Completely agree with this.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. 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) . A problem I can see with fuzzy searches is how to set the boundaries that define where extra characters can be present.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 <[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" <[email protected]> wrote:We can probably implement it ourselves as a wx based control, The JS implementation is only 100 lines. https://github.com/mattyork/fuzzy/blob/master/lib/fuzzy.js You don't need a C++ library or anything 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 |
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
