D6355: Group abstract overrides in clang completion

[Friedrich W. H. Kossebau]

kossebau added a comment.


  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.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D6355

To: apol, #kdevelop, kfunk
Cc: kossebau, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170627/b8b29af0/attachment.html>