I was referring to @mwolff's comment D17289#395163.

To some extent that problem is going to disappear as soon as concepts are more widely used. GCC ≥ 6 already supports them and I expect Clang to follow suit — there is already a prototype.

In D17289#399019, @rjvbb wrote:

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?

so, I believe we need to change some things here...

please just push it to master

please add tests for the features you add - it's probably enough to add one or two files to tests/files/ and use the JSON comments to verify everything is parsed properly?

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?

In D17289#398555, @rjvbb wrote:

In D17289#395491, @aaronpuchert wrote:

Temporary files being left behind after a crash is not unusual. This is why systemd has systemd-tmpfiles --clean.

Not really relevant outside of the systemd realm, right? :)

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:

I haven't pushed anything since KDE svn days but my account should be set up I think. One way to find out. Which branches? master and 5.3?
Or just 5.3 and you're merging to master once in a while?

without digging into the patch myself (I'll have to see whether I can find time for this), could we solve more of the open TODOs by reporting problems for *all tail* child diagnostics that point at the current file? And then reference the "parent" from them somehow? I.e. I believe currently, we have something like this (bare with me, it was quite some time since I worked on this):

unrelated - but potential future work: does keyboard navigation work across tooltips? I.e. 'ALT + ARROW'?

I moved the code into helper functions and added an initial version of the tests. The tests for having the function and the call in the same file, and for having a chain of template functions in the same file include QEXPECT_FAIL(). In principle it would be easy to generate additional problems for these cases, but then a single actual problem would be represented by multiple problems in the same file. Maybe it would be cleaner to make a single problem have multiple ranges.

Make helper functions and add tests, as requested by Milian.

I just noticed this old bug: https://bugs.kde.org/show_bug.cgi?id=368460
Should the template parameters be put into a separate context?

Already fixed.

Yes, the behavior of this patch is as described by Milian.

This is how it looks on my system:

Cosmetic improvement to combined problems and decl tooltip

Can you push the change or do you need us to do it for you?

• Fix testcase

In D17289#370477, @rjvbb wrote:

Actually, issues with clang temp files is why I started to think about this kind of change but ultimately I realised it didn't seem such a bad idea at all to put all KDevelop-related temporary files in a dedicated location. I often clean out a bunch of KDevelop's own temp files that were left behind, e.g. after a crash. I just didn't mention them because they're negligible in size (and I purge before their numbers really start to grow).

Updated as requested.

Good point Pino - setting the env var, even temporarily, would induce a race - so we can't do it there.

@mwolff he doesn't want me to commit it meanwhile or do we wait for him to get the account?

-2, I don't want to have tables with word wrapping. Hover the entry to get a tooltip that shows the full message instead. That would be a much better feature addition btw - I just checked and we don't seem to show the same problem tooltips when hovering an entry in the problems view as we do in the editor. We totally should!

please create a test out of the example you have provided

btw - do you have commit rights? if not, then feel free to request them, see https://community.kde.org/Infrastructure/Get_a_Developer_Account

so this patch fixes the tooltip to show up like void foo(char b, char c), but we still don't show the template<int a> information anywhere? I guess it's a good step forward, but we should also show the template args somewhere!

could you show a screenshot of this in action? code-wise I like what I'm seeing, good work! Feature-wise, I also agree that we need to do something about the issue you describe.

can you please also add tests for this feature? Have a look at test_duchain.cpp and in there e.g. TestDUChain::testInclude for how to create multiple files and have them include each other.

I'll be happy to sponsor you.

Sure, thanks. But how do I do that? Can I just push the commits?

Looks good to me. In general I'd say you can feel free to develop the plugin and only run it through review if you want feedback on specific bits.

Well, it is true that this plugins dates from the Kdev4 days, and it is unmaintained. Anyways, with these patch, I correct the plugin to behave as described on

Works great now, thanks!

placeholder text + dropped manpageplugin hunk.

QString --> const auto (for real)

I don't think that I have commit rights. Feel free to commit.

QString --> const auto

I prefer to use AAA, but otherwise lgtm. do you have commit rights, or do you want me to submit this for you?

But these actions are disabled until I open any scratch in the editor.

For example, I have 2 scratches: scr1.cpp and scr2.cpp. I left-click on first one and open it, then right-click on second one and select Run. The 2nd scratch gets executed.

Update according to Milian's comment

You are right, this should be changed. I was under the wrong impression that the original diff worked since it still showed the completion when typing something like "foo1" from the beginning. But actually, if "foo" is already there before and one starts typing at "1", then it failed.

Adds tooltip to the import dialog's "Installation Prefix" entrie widget.

In D17569#391929, @amhndu wrote:

In D17569#391807, @arrowd wrote:

I found the following minor issue:

When I just started KDevelop and open "Scratchpad" toolview, any action except "New Scratch" are greyed out. Even "Remove Scratch", as well as "Run Scratch". When I open any scratch, it turns back to normal, even if I again close all Sratchpad windows.

That's intended. The actions are all associated with the selected scratch in the toolview list. Switching the window to a different scratch also changes this selection, while closing a window keeps the selection.

Note that environment variables are per-process, not per-thread.

In D17569#391807, @arrowd wrote:

I found the following minor issue:

When I just started KDevelop and open "Scratchpad" toolview, any action except "New Scratch" are greyed out. Even "Remove Scratch", as well as "Run Scratch". When I open any scratch, it turns back to normal, even if I again close all Sratchpad windows.

Milian Wolff wrote on 20190112::12:35:11 re: "D16882: [KDevelop/Shell] prevent duplicate added contextmenu actions"

• Fixed build options order
• Refactored new build dir to avoid duplicate configures
• More polish for the New build dir dialog

In D17289#391849, @mwolff wrote:

Though probably it's going to be enough for now to set TMPDIR temporarily in the background thread where we launch the parse job via libclang?

-2 from my side - we change the behavior of all (sub)process launched by KDevelop and that's not something I want to do. you've seen it affect a sub-kdevelop process, but what if a user launches his own app through kdevelop? we shouldn't change the temp dir for these apps.

But that's not related to your change, so please push it. Not sure where to, 5.3, I guess.

I found the following minor issue:

The problem with current revision is that pages added in uicontroller.cpp:530 aren't sorted.