+1 from me, but let apol review it ;)

Fine with me.

I understand what the patch does, but can you explain why this fixes your issue?

Good find, please submit to 5.2 :)

40 characters or 25% of the view's width, whichever is smaller?

Random thought, not sure if useful/technically feasible: the border could also behave like a splitter, allowing to resize it.

Looks cool! The panel is extremely wide, maybe we want it to be a bit less wide ...?

LGTM

Looks good, thanks!

No, no objections, it doesn't really do any harm. Thanks!

In general looks like a good idea and I admire your persistence, but do we really want 3k lines of code of tests testing copy constructors? Does that add value? It seems like it just makes any future changes harder ... It only tests that the compiler-generated code actually does what the compiler claims it will do, no? ;)

Yeah, the problem with kate plugins is that we have no way to distribute them. We don't have infrastructure for distributing binary plugins, and we don't really support script plugins, and nobody installs your plugin if you put it on github with compile instructions. I'm not sure what that means for this case, I'll leave that decision to the maintainers I think.

Hmm, I'm not sure -- this is quite a bit of code for a feature I personally wouldn't know how to make use of. Yes, I sometimes want to perform this action, but really, I just press Ctrl+C, Ctr+N, Ctrl+V and I have achieved the same thing -- and it's much easier to remember than another shortcut for specifically this ...

Yes, at least the ones I'm aware of. Thanks for the review, I'll push it in a moment.

Future tags won't drop the v, because all KDE apps always have the v there.

• This only works on UNIX
• This adds a hard build-time-dependency on git, doesn't it?

I grepped around and I a) can see why not setting this key breaks things and b) don't see why it would be wrong. I think it's just an oversight that it wasn't. Thank you!

It's a hack but meh, why not. It's not like the "sort selection" script wouldn't have the same problem. While you're at it, probably #ifdef that one as well ...

LGTM

I also think by the way that this shouldn't go to 5.2, sorry ... 5.2 is fragile enough as it is on the platforms we already claim to be stable on. Let's put it in master and instead try to keep the time to 5.3 short-ish.

Looks good to me, thanks! Maybe wait for Milian to approve as well.

My position stays the same: are we really in a situation in 2017 where, from the kernel POV, we cannot get notified of changed files in a directory tree without 30+ seconds setup cost? Only if that is the case (and I'm quite sceptical) I'd say this approach is a good idea.

Otherwise, looks good to me, thanks a lot!

In D7979#148773, @mwolff wrote:

Imo this should be done in the clang plugin. Other plugins may want to know the "full" args, so filtering in the IADM is too early. Only for the purpose of clang do we want to filter this out.

I was experimenting with a similar patch locally and yes, I think this should be done on the higher layer as well. Otherwise, you need the same patch for e.g. qmake.

Looks good to me! The issue it (I think?) fixes is quite annoying, so go please submit and thanks :)

Looks good to me, thanks!

The deferred starting of the parsing. The dirwatches, sure -- if they are that slow on mac, another solution is needed.

Rene, did you actually read the comments I made on the other RR? I'm fairly sure that is the result an in-depth performance analysis will show too, and I'm faily sure your workaround is not needed if the performance *bugs* this code has are fixed ...

In D7745#146271, @rjvbb wrote:

Rene, maybe you want to look into this?

This sounds like it could well be something requiring a substantially deeper understanding of the underlying architecture than I have (and wouldn't normally seek out just for fun ;))

Or rather, let me rephrase: The first point is IMO the much worse bug, since that is what will cause large project imports (think clang) be very slow in either case. For completely no reason whatsoever.

Ok, here's the two things that are broken and need fixing:

I just poked around a bit myself. It indeed takes ages to import the project, and I couldn't figure out why ... it is certainly not CPU load. I looked in perf, the CPU time spent in importing the project is quite low.
In fact, the code model generation (which seems to be the last step in the import AFAIU) finishes relatively quickly here (after something like 5 seconds), but then it still takes like 30 seconds for the import to finish. I don't know where that time is spent.

Ok, you're right ... I looked some more. Try "-pipe", qmake passes that here, that seems to be what breaks things if I'm not mistaken.

There are some arguments which we shouldn't pass on, for example I have a qmake project here which does QMAKE_CXXFLAGS += -Werror=return-type and that completely breaks everything (no highlighting any more whatsoever, parsing of all files fails, ...), Not even sure why, but I guess -Werror arguments should never be passed on in our case.

Re. IRC: Yes, to 5.2 I would say. We didn't release our beta yet, and I even think this counts as a bug fix ...
Thanks a lot!

Looks sensible, thanks for investigating!

Do you have some timing on how much loading time improves with this patch?

range-based for would detach ...?
If you had a reason not to use that, LGTM, thanks!

Releasing with applications makes sense to me, I feel like it should be released in sync with kate.
If there is a hard dependency anyways then I agree with Dominik that we should move all plugins over. All of them are possibly useful for an embedding application, and with moving just some I see us moving plugins back and forth all the time for no real reason.

Looks good, thanks!

Good solution I think, better than the hack from before (because it actually does the right thing, in a way). Feel free to put it into 5.2, we still have a few weeks to catch issues it causes. Thanks!

I can write a test if you think this helps. I think reading the docs it is quite clear we must call updateGeometry() here: our sizeHint() changes when changing the text.