Ok, fine with me, I don't care much about the type. I just stumbled upon the comment and then noticed the type as well. Thanks for the patch, all fine from my side :)

Submitted with f30ef7c6f1376 to 5.2, sorry, I forgot to set the diff in the commit message.

Good find, the previous code (remove item -> call beginRemoveRows() -> call endRemoveRows()) definitely looks wrong. Can you submit this yourself?
Otherwise, I'd need an email address to set as the commit author.

Now I would compute the fileInfo's canonicalPath only once (it might require a stat) and then this looks okay :)
I can't accept it apparently because the discussion is still open ...

Yes, that looks reasonable.

I'd like to play with this a bit wrt what can be done in KDevelop with it (I want the problem popups gone). Would you mind if I do some changes along the way? I would post an updated patch here, in case I actually come up with useful changes ...

By the way, other people around here are very impressed by this patch as well, and we'd really like to get this merged :)
Moving e.g. KDevelop's warning markers into an inline note instead of the annoying popup would make a real difference for usability ...

Wow, that looks amazing! Really impressive.

In D14758#307401, @ngraham wrote:

In D14758#307333, @brauch wrote:

The "overly sensitive touchpad" issue seems to be missing accumulation of scroll events, so this patch to my understanding should not have it.

Yeah, I don't think that's our bug, and we shouldn't work around it here. The reporter should file a bug against libinput.

The "overly sensitive touchpad" issue seems to be missing accumulation of scroll events, so this patch to my understanding should not have it.

I will modify the commit message as suggested.

Ok, I'll submit it later today then.

This looks good to me, feel free to submit it (can you?). Thanks!

Yes, that makes sense to me.

Hey there, what's happening to this? I think this is a really nice feature and it would be very sad if it would bitrot :(
Anything anyone can assist with? We are currently at Akademy, KDE's annual conference, so we would have time to discuss any issues right now.

We should try to figure out what code leads to creating a function declaration with no function type assigned, but this check makes sense in any case. Thank you!

That said, I can understand your mood (I've felt the same before with things I submitted somewhere, I think everyone has) and I'm sorry for it. But I agree with Kore that we should try to merge patches based on what objectively makes things better.

In D14408#299308, @loh.tar wrote:

Thanks for the hint.

Right now I'm not in the mood to do this, and a look at the hotspot dependencies in AUR make it even worse.

Just install perf and hotspot, then compile in "RelWithDebInfo" mode and run

Looks reasonable to me. Can you submit the patch yourself or should I do it?

No, this looks good to me. Thanks!

Of course, nobody is exactly sitting here thinking "eeh, now I've been waiting for that guy for *weeks* to get his patch in" ;)
If you need advice, feel free to ask.

No, I think you should introduce a way to get the session name before the colon is added. You can introduce a new role for the item model for example, have a look at QStandardItem::setData.

Try opening a few projects in the session. The names of these projects should follow the colon afterwards.

AFAIK that is followed by the names of the projects open in that session, and that is also where your approach with chopping of the chars will probably go wrong.

In D13444#281056, @sagnikchaudhuri wrote:

Can I get an instance when chopping off the last 3 letters won't work? Like, shouldn't the last 3 letters always be ": "
Or will it change if the name of the session's too big or something?

KDE only uses github as a read-only mirror. You will get a notification when it is submitted.

Otherwise looks good, I can submit this later.

Ah, cool. In that case I would need your email address to set you as the author of the change.

Looks good to me, thanks! Can you submit it yourself?

Yes sorry, I felt too tired yesterday to correctly resolve the version number merge conflict ;) Done now.

Looks like it was already fixed for Qt 5.11.1, e15fc26e9fdbff141890a3e2e8dc4ef935d022a0 sounds a lot like it:

I'll dig around a bit and see if I can find the change in Qt causing this. In the meantime, do you want this in applications/18.04 or master only?

What happens if the overload selection window is open in addition (like in KDevelop)?

Oh, heh, yes it does. It's just the docstring which says otherwise ("is an interface for the View"), and that's what I looked at at that time. That should be changed. ;)

I think fixing the selection rendering issue would be nice.

Looks good from the implementation too so far. One thing I do not see is any changes to the cursorToX / xToCursor functions, is there really no change required there?

Awesome idea! Do you have a screenshot of how it looks?

Didn't do super much C++ since but didn't notice anything. Thank you!

Given the amount of problems we had with this in the past, I think this change makes perfect sense. I applied the patch here, I'll see if anything breaks in the next few days ...

I think the change makes sense, I applied the patch here, let's see how it goes.

Oh and, you do not need to inherit QObject to use connect; you can connect to a lambda calling the member function AFAIK or so. Just omit the third argument in connect(). What you lose by doing this is the automatic disconnect of the connection when the receiver object is deleted, so make sure that doesn't happen.

Re. binary compatibility: should be fine because this class is not exported (no KTEXTEDITOR_EXPORT macro).

I remember seeing this odd behaviour as well. I agree, the changed version makes more sense.

Thank you for fixing this! 5.2 sounds ok to me, but let's not put it into the release we were planning for the next few days (i.e. not in 5.2.2), or should we?

For KDevelop this is fine, I don't think we have any objection.

Change looks good (the previous code definitely looks like nonsense), but what does this mean for existing settings, saved previously?

Makes sense for me, I'm not aware of any common global shortcut using Alt+F9. Do you have commit access?

Uh, good find. Thanks for the patch. I should somehow have used a mutex locker for that ...

Looks good to me, thanks!

Looks godd, thank you!

I looked it up, it depends on the file system. NTFS always uses UTF8, but FAT uses some weird 1980's charset. So I think this breaks if you open files from FAT file systems.

Looks good to me, also because null termination sounds better than \n (filenames can easily contain \n although they usually don't).

I'll add some people who have recently been working on kdev-php.

Heh. Fix looks obviously correct to me (good find), and tests are always nice.

After this was submitted master doesn't compile for me, and if I fix the compile in the trivial way the test fails. Can you have another look?