Re: fuzzy-matching in quickopen...
Alexander Neundorf <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kwrite |
|---|---|
| Message-ID | <2611304.q0ZmV6gNhb@unknownc4d9870202f1> |
On Freitag, 16. September 2022 18:21:52 CEST Christoph Cullmann (cullmann.io) wrote: > On 2022-09-16 16:25, Waqar Ahmed wrote: > > 1. After filtering, why should open files always end up at top? This > > is not an "already open files quickopen". If the filter matches > > something else better that will end up at top. There might be cases > > where an openfile is a better match, perhaps there is a way to improve > > that without biasing 100% in favour of open files. > > > > 2. Match in sequence will take precedence once you have typed 4 or > > more letters. With 3 or less letters, we can't be sure if that is a > > sequence or an abbreviation. e.g., ftv will prefer "FilesTreeView" > > over "abcftv.js" > > > > 3. That is correct and working as expected. > > > > Quickopen is not meant to filter already open files. For that, you > > have other plugins that can do the job. > > > > If you have a concrete case where X is a better match, discussing that > > would be better. > > The question is, if some people liked the very old behavior of > preferences for > open files, if somebody provides a patch to make this configurable via > the > context menu (as we have already for the project scope), I think that > would be > acceptable. > > A config option in the context menu is non-intrusive and will IMHO > annoy nobody. I created a merge request, it let's the user select "Fuzzy search" or "Wildcard matching": https://invent.kde.org/utilities/kate/-/merge_requests/897[1] Alex -------- [1] https://invent.kde.org/utilities/kate/-/merge_requests/897