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

you are doing really good work here and in the other changes!

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

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

Regarding commit rights, I applied for them now, but feel free to commit directly in case you want to have it in @aacid .

Regarding showing the template arguments in the tooltip as well, KDevelop's behavior seems a bit inconsistent at the moment. If you have for example this template class:

template <int A>
class TemplateClass {
  int SomeFunction() {
    return 0;
  }
};

Hovering over "TemplateClass" will not show any template arguments. However, hovering over "SomeFunction" will show "Container: TemplateClass<A>" in the tooltip. This is because the template identifier info is explicitly removed from the main tooltip display. But even if disabling this, it will only show the names of the template arguments, not the types. So, I might look into this when I find the time for it.

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?

@thomassc: A separate context could help, yes. But if you find alternative ways to handle it, like proposed here, then not using a separate context could potentially work out too. But it feels a bit hackish to handle the template args specially everywhere instead of putting them into a proper context.

Note that we currently don't show the template args in:

• code completion signature
• outline/quickopen signature
• navigation tooltip

all of that should be fixed, and I believe a separate context would be the best way to do that