Choose Symbol filter behaviour odd

[David Pearce]

This was reported on the forum and I can reproduce it.
Windows Nightly
Enter Eeschema
Place Symbol
Enter cp in the search box
There is no result shown because the found symbols have actually scrolled over the top of the window

Application: kicad
Version: (2018-01-21 revision 81642dddd)-makepkg, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

[Oivind Toien (otoien)]

While I can reproduce it, it seems a bit variable how far past it scrolls. For instance cp1 will take you to the next symbol symbol, CP1_small under device, scrolling past CP1, some others again scrolls way past if there are many different search results, while it will go to the correct result if there is only one result.
Tested with latest Windows Nightly (2018-01-21 revision 81642dddd).

[Oivind Toien (otoien)]

Might be a regression, in bug report # 1739412 I reported that the sort was normal after the fix (although the tests then could possibly have missed it). It is also worth noting that just cp will find a number of results with that letter combination in it, thus scrolling way past it. (On my system it ended up on Analog_Switch which when expanded contains MAX312CPE.)

[Oivind Toien (otoien)]

Correction: It goes to the last search result found, for CP it points to Interface_ethernet on my system which contains W5100 which in the description contains the expression TCP/IP.
There is a similar bug in Libedit, also going to the last found item. Could this bug be a remnant or regression from when the list was sorted in the wrong direction (bug #1739412)?

[David Pearce (halzia)]

It makes it hard to find character selections like BCxyz transistors

[Seth Hillbrand (sethh)]

I'm not sure if this is the same bug, but I'll add this here because it seems relevant:

On my machine, the filter action is not predictable. Linux nightly build. For example, if I am searching for a shift register, I might filter using "Shift" as a keyword. This gets the 75LS299 but misses the LS165, which also has "Shift in the description. So, I might imagine using the Keywords field, searching on "SR8". This _only_ pulls up the 74LS91, even though a number of others have this keyword. The only way I have found to actually get the 74LS165 to show up in my filtered search is by typing "LS165".

The attached image shows this situation.

Application: kicad
Version: (2018-02-06 revision 11cd74c38)-master, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.52.1 GnuTLS/3.5.8 zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Platform: Linux 4.9.0-5-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    Curl: 7.52.1
    Compiler: GCC 6.3.0 with C++ ABI 1010

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=OFF

[Seth Hillbrand (sethh)]

The attached patch resolves the issue I was seeing. Component search keywords were not case insensitive, while the name, and pattern match were.

[Maciej Suminski (orsonmmz)]

Seth,

Some time ago Jeff has implemented lazy normalization to speed up populating the component tree. What do you think about the attached patch? It keeps the lazy normalization for the whole search string.

[Seth Hillbrand (sethh)]

Orson-

I'm not sure which commit it was, but I can't re-create the issue with current master.

[Maciej Suminski (orsonmmz)]

I suppose Jeff's lazy string normalization fixes it, thanks for verification.

[David Pearce (halzia)]

The odd behaviour is unchanged for me on Windows as of r9401
I would rather see a search for abc* rather than *abc* by default unless you actually type "*abc"

[Wayne Stambaugh (stambaughw)]

@David, you did not indicate that you wanted the search behavior changed when you submitted this bug report. I understand your argument but I'm not sure if this is the behavior most users will expect. In the future please make your bug reports more specific. Your last post would have been far easier to understand what your issue was.

[David Pearce (halzia)]

The core problem is still that if you type "cp" no symbol is shown and no tree is displayed open.
Yes, the "CP" part is actually displayed in th opened device tree off the top of the window, but you have to know that. For a novice user it looks like no part was found.

I only said that the leading wildcard in search might not be ideal as it picks up too many random text strings in descriptions, debating changing this can wait.

[Oivind Toien (otoien)]

I notice this problem is still present as described above in latest Windows nightly. Version: (5.0.0-rc2-dev-609-g21ceb786a), release build while the report is marked as "fixed". Is it possible to make the cursor land on the first result found instead of the last one? There would be no need to change the mechanism of the search results, just correct where the focus is placed - to the beginning of the search result list instead of the end.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 9edfd25b954cba897a5c5a897c90d18098749c94
https://git.launchpad.net/kicad/patch/?id=9edfd25b954cba897a5c5a897c90d18098749c94