Bug 407103

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?

https://bugs.kde.org/show_bug.cgi?id=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 sysadmin@kde.org and they'll fix up everything for you!

I can take a look at the diff on github, too.

https://github.com/wm4/kate/commit/3f70b55f77c49593b8f9a17187a717a452915f79

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?

ping

Created attachment 121321 [details]
patch

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.

Hi, thanks.
I can push that for you, but I would need some name to attribute the change for the licensing.

Created attachment 121322 [details]
patch2

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
linear search.

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

https://commits.kde.org/kate/2fdd8c14268e8af93e6515d916db6e72cccc7a7b

Thanks.

*** Bug 404212 has been marked as a duplicate of this bug. ***