Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
refactor: utilize latest lsp_utils #33
refactor: utilize latest lsp_utils #33
Changes from 10 commits
19a6a4a
512e6f7
13eab63
62df060
75ae679
82edca3
5136bcb
30ccbed
44f174d
798bc6b
ef7c4e4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might sound like a crazy idea but this
get_plugin_setting
wouldn't be necessary had we put ourdev_environment
inside thesettings
object.The server will ignore unknown properties anyway and we'll get the benefit of merged settings automatically (not that important in this case but could be in other cases).
Notice that it's already happening (in VSCode at least) as the
python
settings are not really pyright specific in VSCode and the server still receives all of them.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not against that but probably adding an extra prefix like
sublimelsp.dev_environment
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel it's really necessary. We should treat those settings as ours as that's how normal users see them. Users don't need to know the distinction between our and original pyright settings.
IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
having a dedicated prefix makes it more structured imho. now we only have one settings though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with a prefix but not sure what it would be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I propose using the package name as the prefix, i.e.,
LSP-pyright.dev_environment
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry but it sounds very redundant to put a
LSP-pyright.*
key inside theLSP-pyright.sublime-settings
or inside theLSP-pyright
object in project settings, for example.I think it only achieves peace of mind for you, and possibly other developers working on the plugin, because you want to keep the settings of pyright and our additions separate. But as I said, I don't believe those should be treated as separate. To normal users, there is no distinction really.
That setting is a bit special as it affects/modifies other settings though. So from that perspective, I guess it might make sense to single it out somehow. But I really can't think of anything better right now. Personally, I would think that a name like
environment_type
would be enough.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it imply only
dev_environment
(whatever its name) will be in server settings but not other non-server settings in the future?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that implies anything as we don't have strict rules for this. I'm just trying to think of what's best to do here.
But in the end, it's a trivial thing and we should probably not spend too much time discussing it.
Maybe just keep as it is now, even if it complicates the code internally...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I guess that can be discussed later if wanted. https://github.com/neoclide/coc-python#options seems to just use
python
as the prefix.