add config for semantic-tokens-plugin for mapping from hs token type to LSP default token type

[soulomoon]

This would provide configurability for semantic tokens #3937
Things that is done:

1. Add tokenMappings to config of semantic-token-plugin
2. Add test to see if modification to tokenMappings is working
3. Fix some leftover issue in add doc and ci test for semantic tokens #3938
4. ajust this part in the global config test

default config for semantic tokens:

        "semanticTokens": {
            "config": {
                "class": "class",
                "classMethod": "method",
                "dataCon": "enumMember",
                "function": "function",
                "patternSyn": "macro",
                "recField": "property",
                "typeCon": "enum",
                "typeFamily": "interface",
                "typeSyn": "type",
                "typeVariable": "typeParameter",
                "variable": "variable"
            },
            "globalOn": false
        },

[soulomoon]

Configuration is implemented, @michaelpj @fendor
See if this look good ?

[michaelpj]

The main thing is I think it would be better with one option per mapping, although I'm not sure how to do that. Maybe @fendor knows having looked at the config stuff recently?

[michaelpj]

haskell-language-server/ghcide/src/Development/IDE/Plugin/TypeLenses.hs

Line 107 in 034b33e

properties :: Properties '[ 'PropertyKey "mode" (TEnum Mode)]

Seems to have an example of enum properties. Looks like each one will need its own descriptions of the enum members, but you can share that on the Haskell side.

[soulomoon]

haskell-language-server/ghcide/src/Development/IDE/Plugin/TypeLenses.hs

Line 107 in 034b33e

properties :: Properties '[ 'PropertyKey "mode" (TEnum Mode)]

Seems to have an example of enum properties. Looks like each one will need its own descriptions of the enum members, but you can share that on the Haskell side.

thanks for the link. Switching to this method.

[soulomoon]

See if this looks good, I use Enum property for each token type now @michaelpj

[michaelpj]

Just some comments about the naming and stuff. I think this does matter since it's user facing so it's worth making sure it's comprehensible to people

[michaelpj]

I don't know whether we might want more configuration options later, but perhaps it would be wise to nest all these in config.tokenMapping or something?

[michaelpj]

I guess this is the main remaining question. Not sure if it's going to make that much of a difference or not 🤔

I guess the alternative would be to suffix the option name with Token? So we could have config.classToken which is relatively clear what it's doing...

[soulomoon]

I don't know whether we might want more configuration options later, but perhaps it would be wise to nest all these in config.tokenMapping or something?

I think this one would be better. I am going to extend the properties api to better support nested configuration.

[michaelpj]

Is this less code than defining them manually? ;) It's only 11 items. Up to you though 🤷

[michaelpj]

Yeah, the general output looks great

[fendor]

Maybe @fendor knows having looked at the config stuff recently?

Sorry, I don't have any insight in the config specification itself

[michaelpj]

I think in the short term just suffix-ing the options is fine, e.g. classToken.

[soulomoon]

Sure, let's fix the name and try to merge this one first.
I can come back to open another pull request for the nested solution once things in #3944 is done.

[michaelpj]

Yes, although generally it's better to avoid changing config names since it messes up users

[michaelpj]

Nearly there, just a couple of things that shouldn't have been checked in, then I think we can merge.

[michaelpj]

Has conflicts now

[michaelpj]

Test failures seem genuine?

[soulomoon]

🤔 fail again I'll take a look

[soulomoon]

The merge from master create some problems, need manually fixing.

[soulomoon]

It should be fixed now