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.