Kate 18.12.3 (and probably some earlier releases) break the Quick Open functionality fatally. It still "works", but not like it should be. I can observe two dealbreakers:
1. The file list is not LRU sorted. Instead it lists opened files first, and then unopened files, each sorted alphabetically.
2. No entry is selected by default. The second entry should be normally be selected by default. If you bring up "Quick Open" now and hit enter, it creates a new file. Every time. wat.
STEPS TO REPRODUCE
1. Start kate/a new session
2. Open a file (preferably a file from a git repository, with project plugin enabled)
3. Open a second file from the same directory
4. Open a third file from the same directory
5. Hit Quick Open, press enter
6. Hit Quick Open, press cursor key down once, press enter
Step 5 creates a new file. Step 6 does nothing.
Step 5. should open the second file (from step 3). Step 6 should open the first file (from step 2).
Ubuntu 19.04 "disco": https://packages.ubuntu.com/disco/editors/kate
I suspect this commit caused this: https://cgit.kde.org/kate.git/commit/kate?id=d6e38c0cbd3d6d7f7658862757b8c33db4322d7a
But I didn't try to bisect (is that even possible). I didn't try to build master on this non-Ubuntu either, I expect it'd be a nightmare anyway due to KDE frameworks versions.
The bug doesn't exist in 18.08.0 or before, didn't check other releases.
Should it turn out that nobody wants to fix it properly, I suggest reverting whatever caused it. If it was the commit I mentioned: The duplicating issue doesn't seem so important, since this bug exists in other places at least in Kate 18.12.3 anyway, and the speed win also isn't that decisive (still lagged when I tried it on a Linux kernel git checkout).
IIRC this was already fixed in 19.04, right Kate folks?
Are there any instructions for building kate git on debian unstable? Whenever I try the ones on the kate website, it's a mess with dependencies or cmake complaining about something.
Use the kdesrc-build tool. See these instructions: https://community.kde.org/Get_Involved/development
You can also run:
sudo apt build-dep kate
To install all the dependencies for building kate. This requires that you have the source repositories enabled.
Is this fixed already, see bug 403097?
> sudo apt build-dep kate
Well, now I managed to build it. I guess I gave up too early, and Debian removed these packages at some point in the past.
The problem still exists in git master as of today (kate cd54ede58ec80f1d10b). The kate about dialog shows version 19.07.70 (higher than any installed version). All problems I described still exist.
Maybe I'm still testing the wrong thing? It doesn't search for folders, even though 403097 should have been fixed.
You could insert some qDebug() or printf() to make sure you are actually running the compiled version. Or check with strace which files are loaded.
It seems my observations were correct. I checked out a known working version, and it did work.
I bisected it:
90f51f5830e32998d4 breaks selecting the correct entry on show up
d6e38c0cbd3d6d7f76 breaks it completely
So I guessed right, except there was an earlier regression that also broke it somewhat.
All the issues should be fixed on the latest master at this moment.
Thank your for looking at this. I update to kate git 10c552846e73e5ccb342d91d84ef4cf302750fab (didn't change ktexteditor), but unfortunately I can't observe any change. All things I listed are still broken.
Oh, sorry, I tested the wrong thing. It's still broken though.
This fixes "Step 5 creates a new file." (see my first post), but the implementation is wrong. It should do what I described under the "EXPECTED RESULT" heading. All other items are still broken.
Is anyone working on this, or should I try to fix this myself?
If you would like to work on it, please assign this ticket to yourself. If you need help, please check https://community.kde.org/Get_Involved/development
Are there any directions what to do when you get thus message:
Could not find a configuration file for package "ECM" that is compatible
with requested version "5.59.0".
The following configuration files were considered but not accepted:
/usr/share/ECM/cmake/ECMConfig.cmake, version: 5.54.0
There's this kde-build thing, but it starts by building Qt (!). I don't understand this ECM thing. It's updated by a bot?
Please check where to ask for help in https://community.kde.org/Get_Involved/development
The error message is self-explanatory. It expects version 5.59.0, but you only have 5.54.0. The solution is to either compile an older branch, or also compile/install the newest dependencies.
Here's an attempted fix: https://github.com/wm4/kate/commit/3f70b55f77c49593b8f9a17187a717a452915f79
Thanks! Please submit your patch using phabricator.kde.org. Here's the documentation for how to do it: https://community.kde.org/Infrastructure/Phabricator
After spending at least 5 minutes after solving these awful obnoxious captchas (that involve google spying on me and/or doing free work for google), and having to retry several times because the kde site didn't accept it (despite captcha marked as solved), I finally got through, and it sent me a notification mail. But when clicking on the confirmation link, the "Username" field is a drop down list with only 1 entry, "Not selected" (and I can't select anything else or enter anything). Clicking "Register Account" then shows this error:
Please fix the following input errors:
Username cannot be blank.
I give up. This is too complicated for me.
I'm sorry you've had a bad experience. Please send an email to firstname.lastname@example.org and they'll fix up everything for you!
I can take a look at the diff on github, too.
On the first glance, the comments about the wrong use of the unstable sort make sense to me, but I must give the patch a try first.
I tried it, both master and your patch.
Your patch solves the described issues.
Would you be OK with me merging this?
=> To merge I would just require a name + email address.
Michal, could you try this patch, too?
For me, without + using master, the symptoms occur.
With the patch, e.g. the sorting is again LRU (aka least recently used or "usage order")
I've tested the patch, most of the stuff seems ok, but I'm getting pre-selected second item (opened tab) all the time when I open quick open no matter which tab is active. Which seems counter intuitive for me (my expectation would be to preselect current tab). Master always selects first one. I guess the point was to be able switch between two tabs quickly? Isn't there a better way to do it then quick open?
I actually though the pre-selected second element was before by intention to be able to quick-switch between the current and previous used document.
I don't think that is harmful, given as soon as you search the matches will be used.
I'd like to investigate whether the performance of this could be improved. My change doesn't make it slower, but it's something that probably needs to be done, and it might require intrusive changes.
If you use the project plugin with a very large project, quick open can take unacceptably long. I tested with the linux kernel (~65k files, ~130ms, feels annoying) and chromium (~300k files, ~800ms, not really acceptable). I suspect it spends at least half of the time in QFileInfo or QUrl, but not sure yet.
(There was some time when kate essentially froze even on the linux kernel, which I think provoked the change that unfortunately resulted in this bug report?)
Michal Humpula, if you open "quick open", and hit enter, it's supposed to jump to the previous file. Since the list entries are sorted by time of last use, the first entry is always the currently opened file, and the second is the previous file. I think this behavior is very useful, since it saves you a random "down" keystroke. The "Last Used Views" switcher works in a similar way and selects the second entry by default.
Selecting the first entry is just a regression.
We could also just not display the current file, or put it at the end of the list. That would do the same job, but maybe more awkward.
I would appreciate further tunings.
But perhaps we shall first apply the patch to fix the behavior regressions.
Would you be ok with that and provide some name + mail address to push it?
Created attachment 121321 [details]
Here's a patch, I think the code is the same, commit message was modified. Feel free to apply it. Still haven't managed to create a KDE account.
I can push that for you, but I would need some name to attribute the change for the licensing.
Created attachment 121322 [details]
If you need an author name, here's a modified name with my real name as author name.
Thanks, will apply this!
The commit hook is unhappy with the e-mail address, can I use the one of the bugzilla comments here?
I'd rather not, this address is just supposed to be a spam sink, and I don't want to use it for "proper" purposes. I don't have any other address I'd use for this purpose either (that's mostly a problem of the address being publicly listed in git forever), so I've set an obviously invalid address. Sorry for being so much work.
Hmm, then we somehow have a small issue here ;=)
I mean, I can commit this with me as author, given the ip rights of this change are limited anyways, but that would be a bit strange, too.
I think I just push that with mentioning you in the commit message and we are done.
Thanks for the contribution.
Git commit 2fdd8c14268e8af93e6515d916db6e72cccc7a7b by Christoph Cullmann.
Committed on 10/07/2019 at 17:59.
Pushed by cullmann into branch 'master'.
[PATCH] Quick Open: fix LRU listing regression
The quick open list used to be sorted by order of access (the old code
called it LRU order). Commit d6e38c0cbd3d6d7f76 broke this.
The first sort() call is changed to stable_sort() in order to preserve
the "bold" field and the new "sort_id" field. A comment warns about this
subtle and easy to break requirement. This change was needed to sort the
file list by LRU (files not in the sortedViews list have no sort_id set,
and thus are sorted below all LRU sorted entries).
stable_sort() should be slower than sort(), although the C++ standard
promises the same algorithmic complexity. On the other hand, this change
also lets us get rid of the openedUrls string list and the associated
The second sort must always be a stable_sort(). This is a bug in the
previous code. It sorted only on the "bold" field, which means
everything else can be reordered as sort() likes. Even if it "worked",
it was buggy.
To completely restore the old behavior, select the second entry by
default in the quick open list. This is so that you can quickly switch
between the two last recently accessed files. The old code actually
selected the first entry if the sortedViews list contained less than 2
elements - keep that behavior too.
Author: Vincent Lang
M +5 -1 kate/katequickopen.cpp
M +13 -16 kate/katequickopenmodel.cpp
M +1 -0 kate/katequickopenmodel.h
*** Bug 404212 has been marked as a duplicate of this bug. ***