Well, at least keep the same Markdown style in the file (## vs. ---...)

Closing, as this Diff got pushed already. See https://commits.kde.org/kate/749fa3b25f0b26c61e0c15004d490d77ce21dea0

Whoops. Sorry for accidentally reopening it to begin with.

Just a had a quick look at the appearance of the popup before vs. after the patch when doing code completion inside the a function call parameter list. Looks more consisten now, thanks!

I like the idea in general, but not really the string representation of the size.

To 5.2 branch please.

Whoops. My code. Sorry.

src/solid-networkstatus/DESIGN also still references org.kde.kded. Please update, too.

Abandoning as this is clearly not the right way to fix the issue at hand.

Nice changes!

LGTM, but I'll let someone else approve.

+1 if it still compiles

Thanks!

@dfaure Opinions?

In D9423#181460, @habacker wrote:

In D9423#181442, @kfunk wrote:

And I agree. There shouldn't be a need to use two different input files. That's the whole point of configure_file(...): the interpolation of values happens *inside* the input files.

This would be possible by using in the service file something like this

[D-BUS Service]
Name=org.kde.kiod5
Exec=@SOME_PREFIX@kiod5

Please let's discuss on https://phabricator.kde.org/D9423 exclusively. This is basically fixing the same issue in a different repository.

And I agree. There shouldn't be a need to use two different input files. That's the whole point of configure_file(...): the interpolation of values happens *inside* the input files.

Could you please squash the commits and just keep this review for all the changes in KIO? Doesn't make sense to have different Phab Diffs for that (makes it harder to review, harder to revert in case, etc.).

In D9210#176407, @kossebau wrote:

In D9210#176395, @mwolff wrote:

this was used by oldcpp, and we could (should!) actually leverage this by kdev-clang to store more information about the parsing environment, such that we can later check whether it has changed and also show the user what was used. That said, maybe persisting a simple vector of strings is enough for that purpose...

Was that in some branch? Grepping with gitk in changes on the kdevelop repo did not have any hits, neither "PersistentSetMap" nor "persistentsetmap.h" (besides the introducing commit itself).

Whatever. Go for it.

Sorry for being late, but I didn't have time to follow up on this one.

Yes. Makes sense to me.