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.

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.

Apart from the generated tag file use case, I'd consider this change to make this special logic a bit less hard because now the normal calltip selection process will continue as for all other languages. Before, it roughly stopped trying find a matching calltip if no constructor tag was found.

Yes, but only for class and struct types which don't have arguments (at least the way ctags works) so the following code won't find any arguments. Again, this patch won't hurt anything and can be merged, I just think the script (if it's not a big problem) should detect this special case and make the output similar to ctags behavior.

It's actually the inspect library which does "smart" things. The script just asks inspect to get the signature for a class object. I would not call this "fake" :).

It's "smart" compared to ctags because the way ctags parses code, the moment it encounters def MyClass: it doesn't know the __init__() so it emits (and will always emit) MyClass without arguments.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.