Nice idea, but the more I consider it the more I am not sure it would improve my personal usage experience.

Usually I have some motivation to (re-)implement some certain virtual method (e.g. following a tutorial or documentation), and then I know already the name and also might not really care if the base method is abstract or not, that is a minor detail similar to constness.
Having to scan two separate lists possibly to find the method will mean extra time spent on many occasions without too much gain.

I see two use cases where having a separate handling of all abstract methods might be handy:
a) when writing some initial dummy class code to get things to build, and being able to see during writing if one missed out an abstract method which then would result in a failed build
b) when starting to write a class which should be concrete, then having all abstract methods being auto-filled-in in one go would be handy (including correct visibility)

Not sure autocompletion should be used for that.

That aside, "Abstract Override" as term should see some more thinking, at least in Scala this has a different meaning :) No better proposal right now myself.

In D6355#119988, @kossebau wrote:

Usually I have some motivation to (re-)implement some certain virtual method (e.g. following a tutorial or documentation), and then I know already the name and also might not really care if the base method is abstract or not, that is a minor detail similar to constness.
Having to scan two separate lists possibly to find the method will mean extra time spent on many occasions without too much gain.

I don't think that's true by far. Leaf classes are obviously more common and it makes sense just to declare them as soon as possible. Note that override entries will disappear as soon as they're already overriden.

Not sure autocompletion should be used for that.

It's been like this since early KDevelop 4, I wouldn't change it now, especially not with the current state where the abstract ones are just hidden.

That aside, "Abstract Override" as term should see some more thinking, at least in Scala this has a different meaning :) No better proposal right now myself.

Do you have a proposal? Otherwise it's just bit-rotting...

Personally, I just see this as a regression from switch to clang.

In D6355#120119, @apol wrote:

In D6355#119988, @kossebau wrote:

Usually I have some motivation to (re-)implement some certain virtual method (e.g. following a tutorial or documentation), and then I know already the name and also might not really care if the base method is abstract or not, that is a minor detail similar to constness.
Having to scan two separate lists possibly to find the method will mean extra time spent on many occasions without too much gain.

I don't think that's true by far. Leaf classes are obviously more common and it makes sense just to declare them as soon as possible.

"them" = virtual methods which are abstract in base classes? Have to say "as soon as possible" does not make sense with me. At least when implementing existing interfaces, then a method being abstract would be no driving motivator to prioritize implementing it, compared to methods with dummy default implementation or ones which need specialisation in my class to make it work. *shrug*

Sounds as if this separate list serves as TODO list for some for implementing subclasses? Hm, would not match my workflows, but people are different.

Not sure autocompletion should be used for that.

It's been like this since early KDevelop 4, I wouldn't change it now, especially not with the current state where the abstract ones are just hidden.

Okay, was not aware this is a regression over cpp, only started to make more use of autocompletion in KDevelop since last year.
"just hidden" -> "not being highlighted as abstract" you mean? But the "= 0" tells this, no?

That aside, "Abstract Override" as term should see some more thinking, at least in Scala this has a different meaning :) No better proposal right now myself.

Do you have a proposal? Otherwise it's just bit-rotting...

"Pure Virtual Override" perhaps?

BTW, this patch reminded and motivated me to finally tackle the issue of duplicated method conpletion proposals, see D6417 :)