fuzzy-matching in quickopen...

[Alexander Neundorf]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20220923/14f2d20e/attachment.htm>