Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Hmm, this would add an init tag for each class in the generated tags file only to satify this special logic for Python (and D).
True, but this is how the command-line ctags works. And it also works this way for user-written code. So for
MyClass(you get calltip containing
__init__(...)and not
MyClass(...)Adding arguments to classes would make calltips look different for user-written code and global tags which I think is confusing.
Yes. I didn't even realize the difference but yes, other users might notice and be confused.
Those additional _init tags are of no other use for the user and just might cause confusion if you get suggestions and lots of additional calltips when writing own init methods.
You get only the
__init__()from the class whose constructor you call for the calltips,__init__()functions from other classes are not shown.
When requesting the calltip for the class itself, yes. If you are requesting the calltip for an __init__ method, all signatures of all known __init__ are shown and this is what I were referring to.
I tried to save adding the the __init__ tags to the generated tags file which seemed unnecessary. But I guess it's also ok to add them there and so have a generated tags file which is very close to what ctags would generate.
Yet, it will add about 1500 additional tags and the file size of the Python standard library tags file increases from 1.2 mb to 1.3 mb.
I'm not that much against your suggestion to add the __init__ methods to the generated tags file and drop this PR therefore.
I just wanted to point out why I did it the other way initially.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.