Add explicit API function definitions #493
Conversation
|
This pull request introduces 2 alerts when merging 51fef93 into 581cba4 - view on LGTM.com new alerts:
|
|
Is there a test that checks the types against the actual Also would be great if we could generate this instead of manually maintaining it. Then we could have a CI bot that sends PRs automatically. |
|
@justinmk That's a great idea! I'm happy to take a crack at auto-generation, or at least auto-verification. The PR this depends on is just collecting dust at the moment and I haven't seen much indication that it will be merged, so I'll probably defer the work until after there's more progress there. |
just auto-verification is enough to move forward. I would even say, let's wait on auto-generation until we get this first phase merged. I think we're ready to move forward with #492 (comment) |
This mostly doesn't change the functionality, as most these functions were already available via the `__getattr__` magic methods (exceptions for things like Window.cursor and Nvim.echo). The goal of this change is to provide proper type annotations for plugin authors.
|
Rebased after merging #492. Failing Windows CI is a known issue, unrelated to this PR. |
justinmk
changed the title
|
Not in favor of this, for same reasoning as in neovim/node-client#199 (comment) : Most APIs should be autogenerated at runtime, if at all. Meanwhile, |
Depends on #492
With the addition of type annotations, there is now a reason to explicitly enumerate the API methods instead of relying on the magic
__getattr__. If they are explicitly provided, plugin authors will get better autocompletion (via LSP) and more type safety guarantees.Since this depends on #492, it has all of its commits. I'll rebase it once merged, but if anyone knows of a better Github workflow for dependent PR's, please let me know.