kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

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]<pavlina.chris@xxxxxxxxx>
>  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]<mark.roszko@xxxxxxxxx> 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:pavlina.chris@xxxxxxxxx
>    2. mailto:mark.roszko@xxxxxxxxx
>    3. https://github.com/mattyork/fuzzy/blob/master/lib/fuzzy.js



> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp