- User Since
- Jan 25 2016, 10:25 AM (86 w, 5 d)
Looks good to me! The issue it (I think?) fixes is quite annoying, so go please submit and thanks :)
Thu, Sep 21
Looks good to me, thanks!
Mon, Sep 18
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 ...
Sat, Sep 16
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.
Fri, Sep 15
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.
Thu, Sep 14
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!
Wed, Sep 13
Looks sensible, thanks for investigating!
Fri, Sep 8
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!
Tue, Sep 5
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.
Fri, Sep 1
Tue, Aug 29
Mon, Aug 28
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!
Aug 17 2017
Aug 15 2017
Aug 10 2017
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.