-
Notifications
You must be signed in to change notification settings - Fork 206
Use Brittany with hsimport when needed #783
Conversation
return (any isFormattedLine ls) | ||
-- Only use Brittany formatting if it's already formatted | ||
isFormattedLine x | ||
| "import qualified " `T.isPrefixOf` x = True |
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 is pretty much like most people write the qualified import, so it is a potential for a false positive. Maybe check the presence of at least two spaces after the next block of text?
The obvious way to check if it's formatted with britanny is to format it with brittany and see if that changes anything. |
return $ IdeResultOk (J.WorkspaceEdit mChanges mDocChanges) | ||
|
||
where hasFormattedImports fp = do | ||
ls <- T.lines <$> liftIO (T.readFile fp) |
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.
Unrelated to this PR, can we consider not using the read function from the Text package? I’ve had problem in the past with locale settings messing up the results.
An alternative is to used ByteString and do a lenient decode to utf8
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.
Could this same issue be causing #667?
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.
Yes, that's exactly how the problem manifests. Should we create a ticket to get this addressed?
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.
@lorenzo We can probably just reuse that ticket, and add some comments explaining that it could be related to Data.Text.IO.readFile
. I just did a quick search and hie does use it in quite a few locations
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 ran into similar issues when working on the PureScript IDE integration, if it's any help we're using these functions to read source files currently: https://github.com/purescript/purescript/blob/b07042fb7b4f6a68c0fdc68b7e51076b7106cfba/src/System/IO/UTF8.hs
Updated to simply always apply Brittany formatting |
I think this PR needs an update. |
Then we can probably merge it. |
…into brittany-hsimport
This allows for plugins to now access config options It also streamlines the process of running the monads from Scheduler Should be expanded upon to move VFS into
Not sure what I did differently but managed to add |
Ready for re-review |
4a2b618
to
9e0f196
Compare
9e0f196
to
8c204cf
Compare
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 really like this refactoring. Left a few comments on things that could be improved
] | ||
|
||
-- --------------------------------------------------------------------- | ||
|
||
-- | For the diagnostic providers in the config, return a map of | ||
-- current enabled state, indexed by the plugin id. | ||
getDiagnosticProvidersConfig :: Config -> Map.Map PluginId Bool | ||
getDiagnosticProvidersConfig :: Config -> Map.Map T.Text Bool |
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.
Why is this different?
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.
PluginId
is defined inside PluginsIdeMonads
, which now imports Config
so its to avoid a circular dependency. This is probably a sign that we should split the module up a bit
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.
Ah, makes sense
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.
Should we not keep it as a PluginId, just define it in a different place? I am not all that happy with it sudennly being Text
, we are losing coherence.
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.
Can this function be moved into LspStdio.hs
to avoid the circular dependency? It feels like it belongs in Config.hs
though. I couldn't really find a logical grouping of Plugin related types to move out PluginsIdeMonads
since they all reference IdeGhcM etc.
Another possibility is that PluginDescriptor
gets moved into PluginsIdeMonads
where the actual PluginDescriptor type lives
Just lf -> return (Core.rootPath lf) | ||
Nothing -> return Nothing | ||
|
||
data IdeEnv = IdeEnv (Maybe (Core.LspFuncs Config)) |
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.
Can you make this a newtype
instead?
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 meant to make this more than a wrapper for LspFuncs, for things that shouldn't change during the execution of IdeM/IdeGhcM/IdeDeferM. Updated it to include the PID and plugins
src/Haskell/Ide/Engine/Scheduler.hs
Outdated
-> IO void | ||
ideDispatcher stateVar caps env errorHandler callbackHandler pin = | ||
-> IdeM void | ||
ideDispatcher env errorHandler callbackHandler pin = | ||
-- TODO: AZ run a single ReaderT, with a composite R. |
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 TODO should be moved to the place where the code was moved to
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.
Should be fixed
Looks like chocolately is down, AppVeyor build should be fine otherwise |
Move getDiagnosticProvidersConfig there too
…into brittany-hsimport
I’m ok with merging this |
LGTM, merge when CI passes |
BTW, I have seen intermittent failures with that test on various branches / ghc versions recently. I think we should try to make it more robust. |
This does a spartan check to see if the imports are formatted the way Brittany formats it, and if so then applies a coat of Brittany to the import code action.
Closes #772
Todo