Refactor plugins and commands now that JSON transport is gone

[lukel97]

• Remove the name and description fields, since they were only used by the JSON transport when querying and can't be seen by LSP
• Similarly remove the bios plugin as it can't be called by LSP, so there's no point in it being there
• Remove CommandFunc new type so we can coalesce the cmd/cmd' pattern into just one

xCmd :: CmdFunc a b

xCmd' :: a -> IdeGhcM (IdeResult b)

[alanz]

Generally in favour, some minor concerns

[mpickering]

I am strongly against removing pluginName and pluginDescription fields, it seems like a step in the wrong direction.

[alanz]

I am strongly against removing pluginName and pluginDescription fields, it seems like a step in the wrong direction.

I agree with @mpickering. They are not needed in the current use-case, but the intention has always been to have some kind of discoverability around plugins, and the ability to use alternative ones, e.g. choose the one that supports the formatter you prefer. Having names and descriptions makes this easier.

[lukel97]

Ok, I will amend this PR later this evening. I’m not sure what options LSP gives us for discovering different plugins, at the moment for choosing the formatter plugins it is just a matter of setting a string inside the LSP config

…

On 23 Dec 2019, at 11:40, Alan Zimmerman ***@***.***> wrote:  I am strongly against removing pluginName and pluginDescription fields, it seems like a step in the wrong direction. I agree with @mpickering. They are not needed in the current use-case, but the intention has always been to have some kind of discoverability around plugins, and the ability to use alternative ones, e.g. choose the one that supports the formatter you prefer. Having names and descriptions makes this easier. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[alanz]

@bubba Thanks. That capability does not exist at present, but I think keeping the info in at the moment is worth doing, we can strip it later if we choose to.

Somewhere along the line I would like to see a much more loosely coupled plugin architecture, which allows us to configure per installation, or per project what plugins should be used.

Having meta information available helps with this. And it is likely it may move to a different place, but lets keep the flame alive in the meantime.

Which directly opposes YAGNI, but anyway.