Hey!

Thank you for the plugin, it is lovely! Could you update the Open-VSX version https://open-vsx.org/extension/jnoortheen/xonsh of extension?

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

Hi! Thank you for this great start!

Could you please:

1. Rename the repo to vscode-xonsh like vscode-python

2. Add topics: xonsh, vscode to the repo

3. Add "Social preview" image in repo Settings-Options:

Thanks!

Hi! Thank you for the extension!

Add ${...} support:

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

It looks like the grammar files are missing in the extension package.
After manually inspecting the packages, I've found that 0.2.2 is the last release to have the necessary files.

Perhaps related to 30560e1 or 232fce8?

For now I've rolled back to an older version, which seems to work fine.

Hi! Thank you for the extension!

Add builtins support (__xonsh__, aliases, print_color, exit):

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

Hi!

I think it will be great to add the xontrib tag to repository topics. I understand that xontrib topic is mostly using for the installable extensions for xonsh. But xontrib means "contribution" and it's not a problem to add this repository to the list of xontribs on Github to get more stars and attention.

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

Hello there
Noticed windows doesn't runs well with this ext until you do
"pyls.executable": "pyls.exe"
Unfortunately this isn't great for cross-os settings sync, so would be better to workaround it at extension level

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

Hi! Thank you for the extension!

Add $variable support that includes $ sign:

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

Currently, all of this extension's configuration variables are of the form pylsp.plugins.[something]. This seems to violate the (implicit or explicit?) convention that configuration variables should always begin with the extension's name. In other words, configuration variables in our case should instead be of the form xonsh.pylsp.plugins.[something].

While using the VS Code Settings Manager, I have been confused when seeing these settings because I didn't realize they were under the "Xonsh Language Server" heading. For instance, if one searches for "jedi" from the search bar, then the search results do not show the headings. Thus, based on the "convention" the search results appear as if "Pylsp" were an extension with its own VS Code settings.

A potential future problem that may arise is: what happens if another extension also tries to make use of these pylsp.plugins.[something] configuration variables? Suppose someone makes a scripting language called Yonsh and a corresponding vscode-yonsh extension which works similarly. If its configuration variables are also pylsp.plugins.[something], then it would be impossible to configure vscode-xonsh and vscode-yonsh independently.

I'm not sure yet what is the proper way to fix this, but I have started investigating...

If I understand correctly, the plugin's client uses package.json's contributes.configuration.properties in order to define configuration variables, all of which start with pyls/pylsp. The client is then configured on activation to synchronize these settings via this pyls/pylsp prefix.

On the server side, this settings prefix seems hardcoded for synchronization here, and the settings themselves seem to be defined through some system involving entrypoints. Then it seems that pluggy is somehow used to decorate functions so that they receive the configuration, but I don't quite understand this mechanism.

A few other interesting observations:

• Using this configurationSection is deprecated. Here it is briefly explained that the old push model for settings has been replaced by a new pull model. Here is a bit more discussion on the topic.
• In my very limited understanding of LSP, and the pull model, it seems that the client is responsible for sending the configuration settings to the server. Thus it seems to me like a client should theoretically be capable of taking the VS Code settings in whatever namespace (e.g. xonsh.pylsp.plugins.[something]) and translating them into the hard-coded settings which the server expects (i.e. pylsp.plugins.[something]).
• I was searching for an example client using the pull model. I came across this as potentially being the new way to initialize a client. But my JS is very bad, so I can't really be of much help there.

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

Autoformatting adds unwanted spaces in shell commands (at least with default settings), for example:

ls -l *.xsh becomes ls - l * .xsh when saving a .xsh script.

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

Hi! Thank you for the extension!

I think it will be great to create distinct issues for everything we want instead of listing in the README.

Add suggestion support in python operator:

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

This extension doesn't work for me for remote development via ssh.
Specifically, I get the error "Unable to find Python language server".

I've followed the installation instructions, both for my local environment (MacOS) and a remote environment into which I ssh (Ubuntu 22.04).
In each case pylsp is on $PATH and if I open a terminal in VS Code I can type which pylsp and see that it's installed.
For local development the extension works well.
But I get the above error for remote (ssh) development.

Any idea what might be wrong?

Thanks for making this tool!

It would be great if this extension could provide a "shell configuration" which would allow you to use Xonsh in the integrated terminal. (Especially since it seemed a lot easier to do the last time I used VSCode).

I believe this would make it a lot easier to use Xonsh, and it has already proven to work for other shells such as nu. I believe the following code in the nu-shell VSCode extension, adds the terminal configuration: https://github.com/nushell/vscode-nushell-lang/blob/main/src/extension.ts#L5-L92

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment