kicad-developers team mailing list archive

[David Godfrey <info@xxxxxxxxxxx>]

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]<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
>