This needed to be a multiplication, not an addition as addition
unconditionally adds points to the score messing up the results.

CCBUG: 455865

keep the lib in apps

apps provides the shared library + kate + kwrite

all stuff i18n'd there is in the kate.pot

When a path is provided, it *must* match for a match to be acceptable.
Only filename match is not acceptable in that case.

Waqar Ahmed authored Feb 13, 2022 and Christoph Cullmann committed Feb 14, 2022

Doesn't really belong in there + will need to move it anyways when we
start using the KCoreAddons fuzzy matcher

Since filenames are very unlikely to contain a '/', take the last portion
of the pattern to match filename because otherwise we just waste cpu
trying to match a pattern that will never match a path.

Also, when just matching filename, if the file path == file name,
give it extra score. Such files are files that are present in project
root dir and matching them directly becomes hard if there are many
files with the same name in the project. Consider:

CMakeLists.txt
src/CMakeLists.txt
...

On typing "cmake"

the first one will appear at top. If one really wants some other cmake
file, one can jump to that easily using path matching: s/cmake

If a file is already opened, give it one extra point. This gives priority
to opened files over non-opened ones by a slight margin and is mainly
useful for cases where you have two files with very similar names and
same score.

kate.h => opened
kate.cpp => not opened

both have same score, but if .h is opened, it will appear above cpp

Reasoning:
Firstly, I think it was just a very poor decision to match both if
filename matched. When filename got matched, it is unnecessary to match
the path and can lead to worse results if we do it. Consider files:

path/to/FileView.cpp
files/views/to/FileViewModel.cpp
...

First file match will happen, which most likely gives us the first file
for a pattern "fv". But then path matching which can ruin this result
and give some other irrelevant match a higher score leading to worse
results in quickopen

In kate, we work with files (from a user POV). User mostly sees filename
and will most likely be matching against file names, and rarely against
paths.

The other benefit that this gives is HUGELY better performance. This is
atleast 2x faster, so with large repos quick open will be much nicer to
use.

if one really wants to match a path, then specifying a pattern like:

src/fv

will do it. This is already supported, so it isn't something new.

this will allow e.g. the KTextEditor implementation
to be able to access the proper most recently used
view without extra interfacing

naturally one will need to adapt the documentation
in the interface, but I think this is nicer than
to expose and extra sortedView thing, given the
sorting should not be that costly anyways

Most of the warning fixes are about range-for usage.

1. We were refreshing the model twice!
2. Using set.insert() to check for duplicates is bad here as we
   keep growing in size..., use count() instead

untitled documents can no again properly
opened via quick open

we will show all of them, too

... to avoid hiding of and confusion with base class method

... such as when removing all / in a path, or when another string might
happen to occur more than only at start or end.

- Cursor isn't set if line is invalid
- Some Event handling is removed as we inherit from QMenu and its just
  redundant
- No input line clear() anymore. Widget just gets destroyed afterwards, who cares

- Allow opening a file at a specifc line:col. This will happen if you
add a ':' at the end and specify line and column. For example:

"kaapp.cpp:201:18"

will open a file the selected file in tree at line 201 and column 18 (if
they exist).
- On clearing filter text, try to restore the sorting i.e., bring opened
documents at the top again.

Signed-off-by: Waqar Ahmed <waqar.17a@gmail.com>

Waqar Ahmed authored Mar 21, 2021 and Christoph Cullmann committed Mar 21, 2021

Signed-off-by: Waqar Ahmed <waqar.17a@gmail.com>

Waqar Ahmed authored Mar 20, 2021 and Christoph Cullmann committed Mar 21, 2021

Signed-off-by: Waqar Ahmed <waqar.17a@gmail.com>

Waqar Ahmed authored Feb 06, 2021 and Christoph Cullmann committed Feb 07, 2021

If filename didn't match, it is highly unlikely that filePath will get
matched. However, if there is a '/' in the pattern, we will match the
path anyways because then we are sure the user is trying to match the
path.

The main reason this is necessary is because matching path is really
slow because paths are long so we try to avoid matching path as much as
we can.