Since you went to the trouble to actually code this up, I figure I might as well try it - and I'm okay with this compromise. Still not exactly my favorite approach, but you made it work fairly well, and it looks useful enough. *thumbs up*
On Fri, Dec 18, 2015 at 11:57:37PM -0800, Henner Zeller wrote: > On 18 December 2015 at 21:57, Henner Zeller <[email protected]> wrote: > > On 18 December 2015 at 21:50, Chris Pavlina <[email protected]> wrote: > >> On Fri, Dec 18, 2015 at 09:40:29PM -0800, Henner Zeller wrote: > >>> On 18 December 2015 at 21:33, Chris Pavlina <[email protected]> > >>> wrote: > >>> > I'm not going to argue about search methods, it'll suffice to say I > >>> > disagree. I don't _want_ to search my library your way, and yes, I > >>> > understand that it can work. > >>> > > >>> > I'm unconvinced that adding one option box is excessive complexity. It's > >>> > not in the main UI, it's in the preferences dialog. What's wrong with > >>> > preferences? Users can ignore those. Most do. Though the preferences > >>> > dialog does need to be reorganized. > >>> > >>> The problem is, that people don't find it. They get frustrated because > >>> they want to search with regular expressions, but it doesn't work. And > >>> they never find the option to set it. > >> > >> Somehow I don't think that wildcard/regex search is going to be a big > >> advertised feature that all the kids will be flocking to kicad for. I > >> also doubt that the sort of person who would want it is the sort of > >> person who couldn't be bothered to look at the options. > >> > >>> > >>> If the dialog would do all matches in parallel and increases scores > >>> for each matcher that triggers, then you get all the simple matching I > >>> am proposing and all the extended regular expression searching that > >>> you want. And it will work automatically without anyone ever setting > >>> an option. > >> > >> Yes, and clutters up the results with false matches, just like searching > >> for "ATXMEGA*D3" by typing "ATXMEGA D3" does. > > > > But if you have all scoring functions engaged, the relevant come first. > > > >> > >> Seriously, what is it with this mailing list? Every time someone > >> suggests a simple idea, everyone immediately piles on with their > >> favorite way to overcomplicate it. > > > > Calm down. I make suggestions to _simplify_, not complicate. > > > >> > >> I just suggested adding this because I thought it'd be a simple addition > >> that might add some utility for some people. Never imagined wildcards > >> could be so controversial. > > > > As I said, I like wildcards and regexp and like to see them supported. > > But I suggested way to support them automatically. > > > >>Take it or leave it, I'm not going to keep > >> revising it to make it more complex. > > > > You don't have to. I can do that. > > Attached, the simplified patch, using your new matchers: > > * Uses all your matchers, but does not need to have the factory. > * No need for extra code to add option for users. > * Same effect. People can use any syntax they want and get matches > accordingly. > * It is very unlikely to get unwanted results. > * Less code (366 vs 833 loc) > * More user friendly to use (no search for obscure options, if > someone uses FOO*BAR or a regexp it just works as expected). > > -h > > > > >> > >>> > >>> -h > >>> > >>> > > >>> > > >>> > On Fri, Dec 18, 2015 at 09:19:54PM -0800, Henner Zeller wrote: > >>> >> On 18 December 2015 at 20:16, Chris Pavlina <[email protected]> > >>> >> wrote: > >>> >> > As discussed earlier today, this patch adds support for both wildcard > >>> >> > and regular expression search to the eeschema component chooser. An > >>> >> > option is added to eeschema options to select the "Component search > >>> >> > method", which defaults to "Simple" (the original behavior). Regular > >>> >> > expression search was added as a "bonus", as it was used as a > >>> >> > stepping > >>> >> > stone to wildcard search. > >>> >> > >>> >> Cool, I'll try it. > >>> >> > >>> >> BUT: I am skeptical I must admit, as adding these features that are > >>> >> undoublty more complicated for the non-software engineer to use and > >>> >> also to choose from. More choices for the user to handle, and I am not > >>> >> convinced yet that it is worth it. > >>> >> > >>> >> I would rather try to make the search as best as possible that a few > >>> >> words will bring the result. If it doesn't, then the scoring function > >>> >> needs to be tweaked. I am a big fan of simple user interfaces... > >>> >> > >>> >> Do you have some real world examples that are really hard to solve > >>> >> with simple string-matching and scoring of the result as it is now > >>> >> (the XMEGA example in the other thread can be done by just having a > >>> >> space between the xmega and d3, so this is not really a good example). > >>> >> > >>> >> Having simple user interfaces is hugely important IMHO, so we should > >>> >> add features and confusing user options only if the simple way of > >>> >> dealing with it can't do it. > >>> >> > >>> >> -h > >>> >> > >>> >> > > >>> >> > The existing behavior of Henner's component chooser wasn't changed, > >>> >> > just > >>> >> > the matching function it uses. > >>> >> > > >>> >> > Following Wayne's suggestion, an EDA_PATTERN_MATCH base class is > >>> >> > defined > >>> >> > in include/eda_pattern_match.h, and then: > >>> >> > > >>> >> > - EDA_PATTERN_MATCH_SUBSTR implements EDA_PATTERN_MATCH with the old > >>> >> > behavior > >>> >> > > >>> >> > - EDA_PATTERN_MATCH_REGEX implements EDA_PATTERN_MATCH providing > >>> >> > regex > >>> >> > search via wxRegEx and wxRE_ADVANCED. > >>> >> > > >>> >> > - EDA_PATTERN_MATCH_WILDCARD extends EDA_PATTERN_MATCH_REGEX, > >>> >> > translating a wildcard string to a regular expression and then > >>> >> > loading > >>> >> > it into the latter. This allows the nice, fast, > >>> >> > wxString-compatible, > >>> >> > and well tested regex search to be reused for wildcard search. > >>> >> > > >>> >> > -- > >>> >> > Chris > >>> >> > > >>> >> > _______________________________________________ > >>> >> > 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
