I have a script that generates the library automatically, so it is strange that some work, some do not. For exampe 100R does not work either. 100K on the other hand, does.
I am using the nightly builds.
Application: kicad
Version: no-vcs-found-1773985~61~ubuntu17.10.1, release build
Libraries:
wxWidgets 3.0.3
libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0 (+libidn2/2.0.2) librtmp/2.3
Platform: Linux 4.13.0-32-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.62.0
Curl: 7.55.1
Compiler: GCC 7.2.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
Is this the same issue? I can see why common values like 10K or 100R would get many hits and might grab the search focus, whereas 510K is probably unique to this custom library
Both left hand and right hand search strings in the image are likely specific enough to likely give a unique search result. In the middle panel, both 910K and 510K are valid search results for 10K, however with the way the listed bug works for me, 10K should have been found further up the list. So, it is a bit strange that 10K does not show up at the top of the the 0805 library - perhaps there is something else going on here. Thinking about it, the listed bug might not affect Linux at all, both reports were on Windows builds. If I remember correctly the solved sorting bug which could be the root of the problem of the listed bug was also Windows specific. The other search results down the list could indicate that, as a windows build would have scrolled all the way down to the last result. ( I am modifying the wording in my post above.)