Remove unused config in hls-class-plugin

[July541]

While looking on #3105, I found type lens itself has a config filed, see haskell-language-server generate-default-config

Remove a duplicate one, although I don't know where is the another one from now.

[michaelpj]

I'm slightly confused, I think we probably do want a config field for the lenses? Or are there currently two or something?

[July541]

Currently we have two config fields for lens, haskell-language-server generate-default-config shows

"class": {
                "codeActionsOn": true,
                "codeLensOn": true,
                "config": {
                    "typelensOn": true
                }
            },

Turns out codeLensOn and typelensOn are the same one.

[michaelpj]

Huh, do we generate a generic config option for any plugin that provides code lenses? That's pretty cool.

[July541]

Huh, do we generate a generic config option for any plugin that provides code lenses? That's pretty cool.

Obviously, it does! Although I don't know where the code is due to time limitation.

[michaelpj]

@berberman ?

[michaelpj]

Dumb question: does the other config option work? Can we keep the test and use the generic config option? Or maybe we can trust it, I'm just suspicious.

[July541]

Both codeLensOn and typelensOn are available. For other plugins, config fields work fine for me.

Can we keep the test and use the generic config option?

It's better if we can(Just because there exists one already). I tried to find how to write the config, but failed as I said.

Or maybe we can trust it

It's ok I think, all of our plugins don't have tests for main ability, we just write tests for custom config.

[berberman]

@berberman ?

Yes:

haskell-language-server/hls-plugin-api/src/Ide/Plugin/ConfigUtils.hs

Lines 84 to 94 in e55004a

	-- This function captures ide methods registered by the plugin, and then converts it to kv pairs
	handlersToGenericDefaultConfig :: DSum.DSum IdeMethod f -> [A.Pair]
	handlersToGenericDefaultConfig (IdeMethod m DSum.:=> _) = case m of
	STextDocumentCodeAction -> ["codeActionsOn" A..= True]
	STextDocumentCodeLens -> ["codeLensOn" A..= True]
	STextDocumentRename -> ["renameOn" A..= True]
	STextDocumentHover -> ["hoverOn" A..= True]
	STextDocumentDocumentSymbol -> ["symbolsOn" A..= True]
	STextDocumentCompletion -> ["completionOn" A..= True]
	STextDocumentPrepareCallHierarchy -> ["callHierarchyOn" A..= True]
	_ -> []

So I think we no longer need the typelensOn in this case.

[michaelpj]

We really need to document how this stuff works...

[July541]

We should have a tech doc to land our tech details while developing hls, but not sure what should be included yet.