Plugins

[alanz]

We now have a proof of concept plugin setup, demonstrated in Ide.Plugin.Example.

What are the next steps?
Should the plugins currently homed in ghcide be moved here?
Should this be used only for migrating plugins from hie (formatters, hlint, etc)?

[jneira]

Well, i think all should be handled the same way at the end but maybe we can start with hie's ones and add value faster.

[alanz]

Yes, I think the formatters are probably the best place to start, and in terms of those start with Ormolu.

[EncodePanda]

I and @lukasz-golebiewski were working in Bristol on stylish-haskell plugin (which we have almost ready, I think PR will land this weekend) in HIE. Should we port it here right away?

[alanz]

@EncodePanda may as well

[EncodePanda]

we will start in HIE, and if that goes through we will add support in haskell-ide

[ndmitchell]

The two plugins in the ghcide repo are Completions and CodeActions. I'm ambivalent about where they live in the long term, but having them in ghcide isn't causing problems, let's us iterate the ghcide Plugin API, and they have great tests where they are - so I'd probably not move them until (at the earliest) after the first release of this project.

I know @cocreature had views too.

[cocreature]

For now, I would prefer to keep completions and code actions in ghcide. Partially because right now, we depend only on ghcide in DAML but not ide and we want to use those plugins and partially because I think it’s somewhat helpful to have a bit more testing surface in ghcide itself to see the impact on plugins caused by changes in ghcide.

That said, if this does turn out to cause issues or there are compelling arguments for moving them over, I’m not opposed to changing this at some point.

[alanz]

@cocreature I tend to agree that they stay where they are for now.

I guess the question will become more relevant if the e.g. completions functionality already in hie is different / better, and we want to make that available here.

[pepeiborra]

It seems to me that the current plugin architecture is not really extensible: it cannot handle two plugins of the same type. E.g. we cannot have two code action plugins, the first plugin that produces a response wins. Fixing this will require some architectural changes in ghcide.

Has anyone thought about this yet?
How much do we care about it?

[pepeiborra]

I guess the question will become more relevant if the e.g. completions functionality already in hie is different / better, and we want to make that available here.

The completions functionality in ghcide was ported from hie by @serras, so that shouldn't be an issue

[alanz]

How much do we care about it?

Quite a bit. The general model in hie has been to be able to specify providers, which get chained together. So multiple sources of diagnostics, code actions, etc.

The current PR (#42) for formatters shows how to select one of n where that actually makes sense.

And these are the two "styles" we should support, in my opinion.

[ndmitchell]

The plugins were designed to be extensible - the important point is that https://hackage.haskell.org/package/ghcide-0.1.0/docs/Development-IDE-LSP-Server.html#t:PartialHandlers gets the existing handlers as an argument, so a partial handler for completions can both answer and get someone else to answer in the same call. It's certainly not been used that way to date, so may not work in practice, but that was the design...

[pepeiborra]

The plugins were designed to be extensible - the important point is that https://hackage.haskell.org/package/ghcide-0.1.0/docs/Development-IDE-LSP-Server.html#t:PartialHandlers gets the existing handlers as an argument, so a partial handler for completions can both answer and get someone else to answer in the same call. It's certainly not been used that way to date, so may not work in practice, but that was the design...

Right, the problem is that Handlers are not composable. Composing handlers 'A' and 'B' using their Semigroup instance yields two independent responses where we would want a single, composed response, and there is no other way of composing handlers as far as I can see.