Updated as requested (minus the potential change to iProjectController::reparseProject).
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 4 2019
Comment removed.
Feb 3 2019
Now tested more exhaustively and with unittest.
No, sorry, I am a bit confused by your notation and the fact you seem to consider only files that are open when you start a session and then probably confused myself a bit more while answering.
Feb 2 2019
where (1) = entire project is parsed on import. Is that correct?
Is Milian's suggestion different from mine of setting the flag only when projects are not parsed entirely on import (which may be easier to test for where the flag is set, I haven't checked)?
Feb 1 2019
never seen this, please investigate and fix it
What I meant is that tooltips in the problem reporter appear when you hover the mouse over an entry, and disappear again when you move the mouse back to the text editor (and certainly when you need to scroll the editor window because the tooltip covers the area where you need to be). But for some reason I'm not getting any tooltips in that reporter at all at the moment.
Jan 31 2019
So according to you, this line is useful ? from my point of view, it's needless and just looks like a syntax error.
Forget that. The syntax is confusing, please remove this HASFLAG
There are tests for other ECM modules in the **tests** subdir.
Updated as requested.
Jan 30 2019
Right, but I was saying all this because I think IF_SUPPORTED (the keyword in the arguments) should be SUPPORTED_IF.
So there should indeed be some real-world benchmarking data to do a cost/benefit analysis that includes the human-in-the-loop aspect and huge projects like the ones Aaron uses. We already have an estimated 10% gain for a full reparse of a small project after its initial import.
In that sentence, one can read "if supported" for the macro name, ...
Jan 29 2019
To put it bluntly: you should have asked that 3 months ago ;)
I really can't remember if I had a specific reason or if this is just the result of a search/replace.
Aaron, don't your arguments apply to parsing an entire project on startup as well? I can easily imagine that opening and parsing entire projects of the size you mention must have a non-negligible cost regardless of all optimisation and caching that is currently implemented
There is a setting for this feature. A similar switch for the preamble thing will probably be difficult to label comprehensively but maybe a coupling can be made with the full-project-parse switch?
Jan 28 2019
This follows David's suggestion, but using QUERY_IF instead of the suggested TRY_IF to make it clear that this parameter controls the querying of the compiler.
I haven't yet tested the new logic exhaustively but the as far as I can tell the macro behaves as intended as used in the two compiler settings modules.
we use CXTranslationUnit_CreatePreambleOnFirstParse to get code completion results fast. otherwise the first code completion request would create the preamble, which felt much worse
On my test file, time spent in clang_codeCompleteAt goes down from ~700ms
Replying to a remark by Milian on D17289 where this idea came up:
Usually if you have a conditional behaviour the associated condition specifies when to trigger it, no?
You're right that the names don't suggest exactly how the condition is being evaluated (with extra checks or not), but that was also a bit the idea.
Don't bother the user with such details, just provide a macro that will add the flag(s) if they are supported, with an optional conditional expression that can make things faster.
Jan 27 2019
Renamed macro and parameter names as announced in my last comment.
In D16894#400949, @dfaure wrote:This makes sense to me. Just the name "SUPPORTED_IF" is strange, when reading that, one thinks "well, if we know the compiler flag is supported, why are we testing that it is?".
like René says, this is quite surprising
Hmmm, did I say exactly that? :)
But still, isn't there another way? Now the header and view are locked together. One doesn't work without the other.
In case someone thinks that creating the pch file when you open a file causes a noticeable lag during the opening process: if so this would also be the case when configuring KDevelop not to parse the entire project on import. I use that mode all the time and never noticed any such lag.
Jan 26 2019
It'd be interesting to have an estimate of how much faster this makes that initial parse.
This is in fact cmake's fault, or ECM's for not taking a cmake quirk into account.
There are mechanisms to ensure cleanup in any event by removing an open file on POSIX compatibles (close will then
See also https://phabricator.kde.org/D16894 which (initially) aimed to tackle this in a more general fashion.
Jan 25 2019
This version saves the original TMPDIR value, and adds a wrapper around QProcessEnvironment::systemEnvironment() that restores that original value. To keep changes to a minimum I've added that wrapper to the Core class itself.
Updated as discussed.
Where or how can I find what to put in the JSON comments?
I was referring to @mwolff's comment D17289#395163.
Jan 24 2019
Use qobject_cast.
As far as I know, using qobject_cast is faster than comparing class names, because it only compares metaclass pointers. Additionally, it allows subclasses.
If you don't use systemd, for example because you're not on Linux, there are certainly other tools for doing the same thing.
How does that systemd thing clean tmp dirs at runtime, IOW, how can it know it's safe to clean up a given file if the application that created it doesn't do something explicit to guarantee cleanup?
David, Andreas, any idea why the name column all of a sudden jumps to a larger width when the widget is used in a side-bar and you're making the view narrower and approach the minimum width? It works in our favour here because the end result is that the name column becomes about as wide as the view itself (and I ensure it won't change size again).
It just nags me a bit that I haven't been able to figure out why it happens...
Jan 23 2019
I completely forgot about this one, for some reason the patch was moved out of my active set (possibly because of lineheight calculation issues).
In D17289#395491, @aaronpuchert wrote:
The behavior is better now, thanks.
Jan 22 2019
the change to the headerfile was now redundant.
Well, that was "interesting".
I'm still going to try to fix this
Yikes, and I can reproduce that. Did you notice this with previous versions that used font stretch? (Probably not if stretch had no effect for the font(s) you tried it with...)
Jan 21 2019
This version uses letterspacing rather than font stretch, so works regardless of whether a stylename has been set on the font.
The discussion in that bug kind of petered out, unfortunately.
Oh sh@@t, I understand what's happening here.
Jan 20 2019
I don't see the squeezed text when using Breeze and Noto Sans. Am I missing something?
Final attempt at being a bit clever :)
One thing we might be able to do is use QFont::setStretch() to make the text a bit more compact. I'll follow that thought for a bit.
I agree that reducing the size column width isn't as easy as I thought. I find it takes up more space than necessary when horizontal space is at a premium and I was hoping to get a more compact read-out that can still be interpreted ... and that would show itself in full in a tooltip.
Jan 19 2019
If there's still enough room to show everything without a horizontal scrollbar, then we're still good.
tentative fix for "very narrow views".
Maybe we can incorporate some more intelligence here
Setting explicit sizes is best done in a mode that supports doing so... =/
Also, sections can be movable (again) now (I often like to see dates first, sizes 2nd).
I realised the 1st version introduced a regression. This update restores automatic sizing when the dialog is resized.
The fix currently has the effect of undoing any column sizing the user may have done before resizing the entire dialog, but that doesn't seem entirely unjustified. It won't be hard to preserve the interactive resize mode for sections that have a custom size but AFAIAC we can put off implementing that until there's a clear demand for it.
Jan 17 2019
Updated as requested.
Jan 15 2019
Jan 14 2019
Should I check if current master works as I intended, WITHOUT your patch, because it does not apply to current master.
Jan 13 2019
placeholder text + dropped manpageplugin hunk.