[prev in list] [next in list] [prev in thread] [next in thread] List: kwrite-devel Subject: Re: fuzzy-matching in quickopen... From: Alexander Neundorf <neundorf () kde ! org> Date: 2022-09-26 20:55:12 Message-ID: 13106877.uLZWGnKmhe () unknownc4d9870202f1 [Download RAW message or body] On Sonntag, 25. September 2022 23:57:32 CEST Waqar Ahmed wrote: > Rethinking some of the approaches, I think we can still improve in some > ways. > > For example, matches which are not at start but still occur at a > separation/camel Hump can be scored better. > > Gap between two matched letters can be taken into account so that really > bad matches are scored lower for example the image-match in your initial > email. This would also improve results for in sequence matches vs matches > that are at separation but the distance is too long. Need to think through > this well though. > > Camel/separation/acronym matches could be scored lower for example when a > letter in between is just a normal match and not a separator match e.g: > > FooBarTaz with pattern "fot". F and T both get full separator scores even > though there is o in between which didn't get matched and thus its likely > this isn't what the user wanted > > More boundaries can be considered, for example a `-` or `/` Sounds good :-) > But all this needs a lot of testing. For you it may seem like, let's just > adjust scores and be done, but understand that I have spent countless hours > even days tuning the algorithm for various things. Yes, I can imagine that. Attached there are two screenshots which show why IMO the bonus for "starts at the beginning" should be small. One shows the results when typing "kate". Many files in kate start with "kate". If I want to get a high score later on, I need to start with the beginning of the word, i.e. "kate", but the list of matching files is still very long with that. So I had to type 4 characters, not to filter out non-matching files, but to get a higher score for what I will type after. The second screenshot shows the result of entering "search". KateSearchCommand.cpp, which is already open, ends up quite far down in the list (with a score of of 291), while the files starting with "search" get scores around 450. How about a config option "Prefer open files" which changes the bonus for open files from 1 to 1000 ? Then the calculation of the score would still have the intended effect, but basically separately for files which are already open and files which are not open ? Alex ["quickopen-kate-prefix.png" (quickopen-kate-prefix.png)] PNG IHDR } ^P\ pHYs + \ IDATx^w|[?jZ${8LIE$@xi)-OR e*{Ea;mK%[{~Hv2~ 9GWѹރ+c 7nX!TLAL w;d|&c|`F*UA uq<Z <Eأ07`E1_|f$ \ 0<iWF @P!x\R[:ףa `؍MoLz \ ?Xc70؍ y1w#A_~nDy( K^6<p|m'o \ 9;n MAhh 6Ƹ}z4AlnmAQ @=!&<cy'yMq>I#" t =9MͶAXcQI3Q CG]$UAYdFҷf PaUc LQ k8y߉Si&FvͬVEA67 `# c00 T0c uΓ&*I?bc \ @0';<k Wisac <iR i3i/ 8?rx@Pd6! \ .SDX 8tfFAG&wzOۄƲ1$ .t豻TƘ \ ]7DjOڋ6Aqp:84غZ@x9Aq'XOeTq7m>c \ qh(}h12>ԿWwNA7ŧH'OZ}JY[WR㑪7J毾=x?> \ e+z[ 97ZpeCp'ADФ <X}p{fϒ#$K{cm/?těW78_vo}j>Fw_ &8!=Q=$D-^~p ЉKG O&teߦ lUn2zw̟ \ xlG9/^&{U+#B4dN~ Cþ7nY. `Op0D/ \ Lms8QX~<='GoZƫOV\7l \ AEEGfߴcIHALjt`d*#kw$U^c3>^YFD)ӳU4:DrZ: v \ N;{Mm-3~F kᱪlY_x蝞&~r "G [půQڧ^+^gw{7IC{S799LCC]kߺq \ ǰ7+#w1GaiN@QhweAT_ΆND" 8]$ \ . 6LvIdA\x99g%S$ ·4S2:|B 5[V0S dFm3' \ X͊<U Nn<iT \ 3jcnuݒ)83y1 :g=x:Aqh"[2s^6 ̋ňK \ 8Nˮ56| \0͈Ό:MNT58]&23NqBpDVvЀ -OM@DH \ /h+̩5A+W%&xΥgNA|i)CG B$ \ .EJiq% \ .AMaYQ@JJJ,k1ߵ}'0P~W\lۯorく \ Nu/xΪy'b6<"ōh:\={wqgw|'>RuҚ \ %)d=)WCЉ9߿nWo3u8OU5w9Mzc]m}ӵ?[mOrn[{}˗_TtGsʽw^} F=uv8vn \ Mm~{]gj}aj>y-skۜ觎Mqϋ%ߟ$ E"aRRo7zu7yM+RLv6C HV8-;?ES;b2 c=/FP4iZ](vpϾ\fD{ΗOW_>BL=vk֤C5vJ=d77W] ml̅ lqG/PŬ(MNx [=$&&G6-w|ᤆy֊e7Ƌi * \ 8W~vW6;E6 S wHꁁaE.O `8hm3{G8J3[#ȁ:盚tnpz^ \ 4 x^cc 4۸{{t^t` )G ;: \ Z<8C Yuw#d.X/.T6WӲ+W-k*Mn&2eVQq]lX8ghW>^~?/-HzkڨY f푽MZ(2-,3F -թwD \ 5s3xݍ:5wiqڜbGQu-~iʴ9ֽGkqr*l`kUhb s䩺l<*[tkH?o^oa^Q"mDG(XSkQ@ \ %f$Jy<F\ڶKdv}8B ɛ \ yeLp|ߗx>`"J1t[<!h g2kB46V@ChV;B,FQ ;]&+DDw \ ׆ 9nBQTD vz*U7]XNv@(G?xa(8&A<yXl#f|X,K"F].kY3Ԗld#T( \ `=y{{Nj O7(YxSP:ƞ^IOVO ?S4-Ĝx_ \ u^nc7dxrO1fk{K ~ H #Fg.X n|,H \ D[/TAn)@$~2ԺCCmVVM˳[~@ %~<