Skip to content

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

Closed
wants to merge 3 commits into from

Conversation

July541
Copy link
Collaborator

@July541 July541 commented May 14, 2022

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 by MaybeT.

Some changes are from pre-commit hook.

@July541 July541 changed the title Add PluginId to CommandFunction & make getNormalizedFilePath takes Uri as pram instead of TextDocumentIdentifier` Add PluginId to CommandFunction & make getNormalizedFilePath takes Uri as pram instead of TextDocumentIdentifier May 14, 2022
Copy link
Collaborator

@eddiemundo eddiemundo left a 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.

@July541
Copy link
Collaborator Author

July541 commented May 14, 2022

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 always get a PluginId from the descriptor or nearby if you do need it means write function like foo :: PluginId -> CommandFunction .., it is. But we can also get IdeState nearby, I think the CommandFunc is the synonym of what we need to build command in most cases, it's the only identifier to identify a plugin, and furthermore when we have more functions into hls-plugin-api, we can call these functions easily without explicitly passing PluginId.

@drsooch
Copy link
Collaborator

drsooch commented May 14, 2022

I'm good with the change, I actually planned on tackling this at some point but haven't got around to it.

@eddiemundo
Copy link
Collaborator

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
Copy link
Collaborator

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.

Copy link
Collaborator

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...

Copy link
Collaborator Author

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

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Collaborator Author

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.🎉

@July541 July541 closed this May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants