Refactor symbol and completion item kinds

[jwortmann]

• This defines sublime.Kind tuples, so that they can be reused for LSP's SymbolKinds and CompletionItemKinds, which have a lot of overlap and even had a few inconsistencies before.
• Also they could easily be used for sublime.QuickPanelItem now.
• No more awkward indexing with kind - 1
• Moved the small lookup dicts for DocumentHighlightKind to core/views.py as well, because that seems to be the place where most of such things are defined.
• Fixes a bug in views.py#format_completion, which would use an int instead of a kind tuple for the kind in sublime.CompletionItem.command_completion, in case there is a kind id in the language server response, which is out of range for LSP's CompletionItemKind.

Changes:

• Removed "readwrite" from "variable.other.readwrite" scope of SymbolKind.Variable (dubious scope only used in JavaScript syntax - https://github.com/sublimehq/Packages/issues/1336).
• Adjusted scope of SymbolKind.Boolean from "constant.language" to "constant.language.boolean" (used in various syntaxes).
• Adjusted scope of SymbolKind.Null from "constant.language" to "constant.language.null" (used in various syntaxes).
• Changed scope of SymbolKind.Event from "storage.modifier" to "entity.name.function" and kind id from sublime.KIND_ID_TYPE to sublime.KIND_ID_FUNCTION (I'm not entirely sure, but I think "Event" is meant to be things like onclick or onchange).
• Changed scope of SymbolKind.TypeParameter from "storage.type" to "variable.parameter.type" (but keep the kind id as sublime.KIND_ID_TYPE). Ass far as I understand, the following is a type parameter (Java example):

  class ClassWithGenericType<T> {}
  //                         ^ Type parameter

• Changed kind id of CompletionItemKind.Folder from sublime.KIND_ID_NAMESPACE to sublime.KIND_ID_NAVIGATION, so that it is consistent with CompletionItemKind.File
• Changed kind id of SymbolKind.Interface from sublime.KIND_ID_VARIABLE to sublime.KIND_ID_TYPE, so that it is consistent with CompletionItemKind.Interface.
• Changed kind id of SymbolKind.Operator from sublime.KIND_ID_FUNCTION to sublime.KIND_ID_KEYWORD, so that it is consistent with CompletionItemKind.Operator.
• Changed kind id of SymbolKind.String from sublime.KIND_ID_MARKUP to sublime.KIND_ID_VARIABLE, so that it is consistent with SymbolKind.Number, SymbolKind.Boolean, SymbolKind.Null.

[rwols]

Nice work. I do think we can optimize to use 1 dict lookup everywhere instead of 2.

[rwols]

The return type should be Union[List[str], List[int]], or am I misunderstanding the use case?

[jwortmann]

Apparently that isn't possible, because mypy can't infer which one of the list types the return value is, when it is used later. See https://github.com/sublimelsp/LSP/runs/7490372297

[jwortmann]

Well, I guess I can add a type hint in this case.

[rwols]

You can run mypy locally by running tox by the way

[jwortmann]

Hm, seems that Pyright and mypy disagree what to do with the type hint comment in f95c500.

So I guess I could revert to the initial return type List[Union[int, str]], or use # type: ignore for the failing line. Or do you see a better solution?

Thanks I will try to figure out how to run mypy locally.

[rwols]

Yeah, eventually it goes into some json anyway. For now it’s okay to use List[Union] :)

[rchl]

Hmm, might not work with inheritance...

[jwortmann]

Let's postpone this to another PR and use List[Union] for now ;-)

Alternatively, there is also the enum module / IntEnum which could be used via https://github.com/packagecontrol/enum dependency.

[rwols]

EnumLike(Generic[T]) looks sweet, but like jwortmann I imagined something like https://docs.python.org/3/library/enum.html. Maybe postpone that until python 3.8 because I don't like more dependencies. Or use the EnumLike(Generic[T]) approach.

[rchl]

That more concise solution using EnumLike didn't really work as it wouldn't be possible to access class method without instantiating an object. And @staticmethod doesn't have access to cls. So it would have to be either the more repetitive solution or some other smart approach.

[rwols]

So the reason for using a List was performance :) a list item lookup is an offset into a contiguous array. But, I guess the performance doesn't matter much. Maybe the dict is even faster, who knows? From what I understand dicts are implemented as hash maps. So a number is run through a hash function before doing an array offset index.

[jwortmann]

I see. As an alternative to the dict, I could use lists and add the fallback KIND_UNSPECIFIED = (sublime.KIND_ID_AMBIGUOUS, "?", "???") as a first entry in the list, then indexing with kind - 1 could also be avoided. But I guess the performance difference (if any) indeed shouldn't matter here and is orders of magnitude smaller than the display refresh time. So it probably doesn't have any impact and would only be a matter of style/preference. And for the lists, there was an additional check if 1 <= kind <= len(SYMBOL_KINDS), which might be even more overhead...