Add _missing_ implementation to StrEnum enums

[rchl]

Add _missing_ implementation for string enumerations that have supportsCustomValues specified in schema.

LSP-json has a code that assigns custom language ID to TextDocument.languageId. That triggers a type error:

Could not assign item in TypedDict. "Literal['jsonc']" is not assignable to "LanguageKind" (reportGeneralTypeIssues)

Adding _missing_ implementation allows us to use a code like:

text_document['languageId'] = LanguageKind('jsonc')

to set custom language ID without triggering type error.

[jwortmann]

TextDocumentItem.languageId is already typed as str (see TextDocumentItem), as well as our LANGUAGE_IDENTIFIERS map at https://github.com/sublimelsp/LSP/blob/3e939772c9a9ead9061e13dbfbda0a157623cb56/plugin/core/constants.py#L281

So you could just do this without any errors, like we do in LSP, no?

text_document['languageId'] = 'jsonc'

[rchl]

In the JSON schema it's an enum so it ends up as LanguageKind - https://github.com/sublimelsp/LSP/blob/1cf96311aab120466fa9c2ee55e128cf7f940f63/protocol/__init__.py#L4677-L4677

[jwortmann]

Hm... that's another point where the metaModel deviates from the specs 😠

(Edit: fixed typo)

I think all LSP types that have supportsCustomValues already use the proper type in the specs, for example CodeActionKind is defined as a string.

[rchl]

It's just the way they handle cases where the value is a literal but also they want to provide some pre-existing values for it.

Perhaps we could just generate those types differently. Instead of creating an enum, create a simple type alias like:

LanguageKind = str | Literal['json', 'python', ...]

?

[rchl]

Nah, that doesn't work that great.

[rchl]

This will work:

languageId: Union['LanguageKind', str]

[jwortmann]

I'd probably prefer to keep the enums restricted to the predefined values.

Would it be possible to make the generator produce languageId: Union[str, 'LanguageKind'] instead of the current languageId: 'LanguageKind', for the types that have supportsCustomValues? The actual type (here str) would need to be derived from the enum type (here LanguageKind is a StrEnum -> str), because I think some relevant enums might also be IntEnum.

[rchl]

Yeah, it's possible but would need refactoring because currently we don't have full enum schema when generating the reference.

[rchl]

Let's get this cleanup merged before I do the follow up changes: #38

[rchl]

Follow up: #39