-
-
Notifications
You must be signed in to change notification settings - Fork 388
Add PluginId
to CommandFunction
& make getNormalizedFilePath
takes Uri
as pram instead of TextDocumentIdentifier
#2906
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
Conversation
PluginId
to CommandFunction
& make getNormalizedFilePath
takes Uri
as pram instead of TextDocumentIdentifier
`PluginId
to CommandFunction
& make getNormalizedFilePath
takes Uri
as pram instead of TextDocumentIdentifier
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 sure if changing CommandFunc
signature is necessary since some of them don't use the PluginId
and it seems like you can always get a PluginId
from the descriptor or nearby if you do need it. The changes in the hlint plugin to reduce duplication and have slightly better error messages are good, but can also be done without changing CommandFunc
.
If your |
I'm good with the change, I actually planned on tackling this at some point but haven't got around to it. |
I see your point about IdeState. I'm not opposed to it, just throwing out some thoughts. |
@@ -389,6 +389,7 @@ data PluginCommand ideState = forall a. (FromJSON a) => | |||
|
|||
type CommandFunction ideState a | |||
= ideState | |||
-> PluginId |
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 not sure this is an improvement. The other arguments to CommandFunction
are things that are only known when the command is run, so we need to pass them in then. But the PluginId
is known when the plugin is created, so we can easily pass it in there. Doing it that way is pretty straightforward, as the tactics
plugin does today.
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.
Plus, most of the existing ones don't use it, so we've also added a bunch of unused parameters...
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.
Only the command parameter is needed to be passed, I think ideState
has the same condition as pluginId
, we can also pass ideState
while we only need it.
Here are the stat about the usage of CommandFunction
.
8/11 use ideState, 3/11 use PluginId, and most of plugins don't use PluginId
because they use MaybeT
to wrap NormalizedFilePath
conversion, I keep this pattern in the pr. I will respect your view if you still believe this change is of little significance.
plugin name | ideState | PluginId |
---|---|---|
completion | ✓ | × |
typelense | × | × |
class | ✓ | × |
eval | ✓ | ✓ |
explicit-import | × | × |
hlint | ✓ | ✓ |
module-name | ✓ | × |
refine-import | × | × |
retrie | ✓ | × |
splice | ✓ | × |
tactics | ✓ | ✓ |
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.
If I may add, like I mentioned earlier I want to clean up all of the duplicate code revolving around MaybeT. So I would plan on removing the MaybeT wrappers. It may end up being more daunting but I expect to need to use some sort of identifier to use in logging messages.
This would also extend to other commonly requested items as well. So it would be nice to have some generic identifier to pass around.
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.
TBH I also think it looks like we shouldn't pass IdeState
like that, if it truly is globally constant. I'm a bit suspicious that it isn't truly constant though, we should check.
I think my argument is that it's unclear what should be part of CommandFunc
. Just any convenient stuff? Then there's really no rule about what to put in there or not. Whereas with my proposal there is a simple rule: it should take exactly the stuff that's only available when you run the command, and nothing else. If you need anything else, just pass it in when you construct the plugin.
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 a bit suspicious that it isn't truly constant though, we should check.
I think my changes have covered all usage of CommanFunc
.
I think my argument is that it's unclear what should be part of CommandFunc. Just any convenient stuff? Then there's really no rule about what to put in there or not.
I believe CommandFunc
is an abbreviation of its arguments and its result, and the arguments can be anything you may use.
I prefer to add something that may not be used to keep the CommandFunc
be unified in most situations.
So I would plan on removing the MaybeT wrappers.
Agree with this.
As I said earlier, I'm going to close this and open a new pr to make getNormalizedFilePath takes Uri as pram instead of TextDocumentIdentifier only.
@@ -246,13 +246,12 @@ allLspCmdIds pid commands = concatMap go commands | |||
|
|||
-- --------------------------------------------------------------------- | |||
|
|||
getNormalizedFilePath :: Monad m => PluginId -> TextDocumentIdentifier -> ExceptT String m NormalizedFilePath | |||
getNormalizedFilePath (PluginId plId) docId = handleMaybe errMsg | |||
getNormalizedFilePath :: Monad m => PluginId -> Uri -> ExceptT String m NormalizedFilePath |
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.
👍
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.
It is indeed much clear and easy to use, I saw many codes can use uri directly instead of TextDocumentIdentifier
.🎉
Further on this comment, I found a lot of plugins can benefit form this change.
I keep the pattern
uriToNormalizedFilePath . toNormalizedUri
if their result is wrapped byMaybeT
.Some changes are from
pre-commit
hook.