Time to rebase this proof-of-concept and restore its full scope, for reference even if only parts ever get upstreamed (there was a blocking disagreement last time).

This patch also changed the logic of openProjectConfig().

I'd appreciate if this were cherry-picked to the 5.3 branch, if/when possible. (I can do the rebasing.)

Sometimes it works, sometimes it doesn't. Often I have to mock-edit a file to force reparsing when some header has changed.

To some extent this resembles the classic latency/throughput discussion.

Well, if among developers you cannot find a solution that covers all use cases a configurable setting (applying only to setting the preamble-on-first parse flag or not) could well be the only compromise. And this one doesn't have to be hard to understand, which doesn't mean it has to (probably means that it should not) indicate exactly what it does.

What's the minimum viable change here?

Or, you add a flag to one of the relevant settings panels. There are already a number of options that aren't exactly easy to understand for everyone, this one could be something like "Make code-completion results available faster (can require significant resources)".

auto* action = new QAction(tr("Reparse the Entire Project"), this);

Updated as requested.

So this is just going to become a victim of the better-is-the-enemy-of-good principle?

Question to @apol: from what I can grasp CMakeTargetItem::m_builtUrl is cmake-internal cuisine so there shouldn't be any need to store it in canonical fashion but rather reason(s) to store it exactly as cmake knows it?

Is the parser triggered again if the entire project has been parsed already?

Updated as requested (minus the potential change to iProjectController::reparseProject).

Comment removed.

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.

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)?

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.

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.

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, ...

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?

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.

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.

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.

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.

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...

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.

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...)

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.

I don't see the squeezed text when using Breeze and Noto Sans. Am I missing something?

My QtCurve-based theme, "narrow mode" just activated:

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.