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.