Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to recognise file extensions other than .py and .pyi? #35

Closed
bzoracler opened this issue May 8, 2024 · 2 comments · Fixed by #38
Closed

Is it possible to recognise file extensions other than .py and .pyi? #35

bzoracler opened this issue May 8, 2024 · 2 comments · Fixed by #38
Assignees
Labels
enhancement New feature or request

Comments

@bzoracler
Copy link

Feature or enhancement

Is it possible for this plugin to recognise other file extensions apart from just .py and .pyi to communicate with pyright-langserver? If it were, a thin wrapper over pyright-python will allow use of this plugin for adventurous Pyright forks developed for non-Python languages.

Proposed solution

Expose ability for user specification of files or file extensions in the Pyright LS settings to communicate with pyright-langserver.

Alternatives considered

No response

Additional context

I was experimenting and managed to get Cython type checking, code completion, and code navigation working by pointing the Project executable to a modified pyright-langserver which launched vscode-cython.

The result worked surprisingly well, apart from the issue that Cython files themselves (.pyx, .pxd, .pxi) weren't recognised by the LSP, so you could only get the benefits by writing Cython in .py files. Cython syntax is, of course, illegal in Python, so IntelliJ IDEs will complain; it'd be great if it were possible to make this plugin recognise user-specified file extensions.

image

Note that include/exclude path settings in a pyright configuration file is not currently possible with vscode-cython, so if that's the only way to make this LSP plugin work, I apologise for posting this in the wrong place.

A way forward for IntelliJ's stagnant support of Cython would be much appreciated. Better Cython support in IntelliJ IDEs has been a feature in demand for years (see e.g. Cython support - CLion, which, unlike PyCharm, doesn't even have basic support).


In case anyone wanted to reproduce this:

  1. Clone vs-code-cython into your platform's <VS Code extensions folder>.
  2. Follow the vscode-cython source installation instructions up to Building source, but run npm run build:cli:dev (instead of npm run build:extension).
  3. Make pyright._utils::install_pyright return pathlib.Path("<VS Code extensions folder>/vs-code-cython/cyright/packages/pyright")
  4. Set the Pyright executable as usual.
@bzoracler bzoracler added the enhancement New feature or request label May 8, 2024
@InSyncWithFoo
Copy link
Owner

Is it possible for this plugin to recognise other file extensions apart from just .py and .pyi to communicate with pyright-langserver?

It is. Simple and straightforward, even. Here's how the language server knows that it should be enabled for .py files:

override fun isSupportedFile(file: VirtualFile) = file.extension == "py"

Adding extensions is, obviously, trivial, but this should be made an optional choice. That is, a field should be added for users to configure the file extensions that they want their language server to run on. As a non-Cython user, I certainly don't want to let Pyright blow up the editor with tons of "syntax" errors in some .pyx file I happen to come across.

That said, this will be supported, but only as a nice-to-have byproduct. I'll work on a PR in a few hours (whose build should be automatically uploaded via GitHub Actions). Since I never worked with Cython, I'm relying on you to test it.

By the by, this issue is finely written. Thanks for that.

@bzoracler
Copy link
Author

I was searching in this repo for the string ".pyi", which is probably why I didn't find that line of code. It seems that supporting user-defined extensions would allow Python users to opt-in into running the plugin against .pyi stub files too, which is a more immediate benefit.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants