Skip to content
This repository has been archived by the owner on Oct 7, 2020. It is now read-only.

Add Floskell and formatterProvider #1080

Merged
merged 10 commits into from Feb 11, 2019
Merged

Add Floskell and formatterProvider #1080

merged 10 commits into from Feb 11, 2019

Conversation

lukel97
Copy link
Collaborator

@lukel97 lukel97 commented Feb 9, 2019

This will expose an LSP config setting for changing the formatting provider, and so should also address #1064

Also worth noting: This moves Brittany off of IdeGhcM so it doesn't get clogged in the request queue, so requests should be faster.

@lukel97 lukel97 changed the title [WIP] Add Floskell and formatterProvider Add Floskell and formatterProvider Feb 10, 2019
@@ -32,3 +32,6 @@
url = https://github.com/alanz/ghc-mod.git


[submodule "submodules/floskell"]
path = submodules/floskell
url = https://github.com/bubba/floskell
Copy link
Collaborator

Choose a reason for hiding this comment

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

What did you have to change in your fork?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Adjust version bounds and tweak it so it builds with earlier and later haskell-src-exts. I've made a PR for the changes so that hopefully we can drop the reliance on the submodule, since it brings us one step further away from #626

@@ -36,6 +37,7 @@ instance Default Config where
, liquidOn = False
, completionSnippetsOn = True
, formatOnImportOn = True
, formattingProvider = "brittany"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could this be a datatype instead of some text?

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 actually originally had this as a datatype! But when adding the pluginFormattingProvider field to the plugin descriptor it made more sense to revert it back to just the PluginId, that way if a new plugin is added the developer doesn't need to edit Config.hs as well.
I do agree though, if there are any tricks to having the PluginIds exported in a more type safe manner then I would much prefer that

lf <- asks lspFuncs
mc <- liftIO $ Core.config lf
-- LL: Is this overengineered? Do we need a pluginFormattingProvider
-- or should we just call plugins straight from here based on the providerType?
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would personally not have this complication and just call the plugin directly.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think having an entry in the plugin is a good thing.

Eventually we can manage config based on the installed providers too, and it opens the way to dynamically (or statically but from config) loading plugins. Which in my opinion has always been a goal.

@alanz
Copy link
Collaborator

alanz commented Feb 11, 2019

LGTM

@lukel97 lukel97 merged commit 5b4f45c into haskell:master Feb 11, 2019
@alanz alanz added this to the 2019-02 milestone Mar 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants