Lsp: Implement documentSelector in dynamic capability registration

[rwols]

The OmniSharp server registers all of its capabilities dynamically. Two of these registrations are for example

:: <-- OmniSharp client/registerCapability(14): {'registrations': [{'id': '98c3fac0-c80e-46ae-86c1-4d6587a41ddd', 'registerOptions': {'documentSelector': [{'pattern': '**/*.cake'}]}, 'method': 'textDocument/documentSymbol'}]}
:: <-- OmniSharp client/registerCapability(15): {'registrations': [{'id': '0baf930f-d735-4017-a5b3-60415c72cec7', 'registerOptions': {'documentSelector': [{'pattern': '**/*.cs'}, {'pattern': '**/*.csx'}]}, 'method': 'textDocument/documentSymbol'}]}

Note how it uses different document selectors for the same capability (documentSymbolProvider in this case).

The first registration uses the document selector

[{'pattern': '**/*.cake'}]

The second registration uses the document selector

[{'pattern': '**/*.cs'}, {'pattern': '**/*.csx'}]

Currently, we don't account for these selectors. Consequently the first registration is overwritten with the second registration.

[rwols]

Another example is

:: <-- OmniSharp client/registerCapability(7): {'registrations': [{'id': '98cccbd2-ac88-4d4f-8344-a041a309e939', 'registerOptions': {'resolveProvider': False, 'triggerCharacters': ['.'], 'documentSelector': [{'pattern': '**/*.cake'}]}, 'method': 'textDocument/completion'}]}
:: <-- OmniSharp client/registerCapability(8): {'registrations': [{'id': 'ac63faa3-e0e3-4ee9-8a97-40f00f34b501', 'registerOptions': {'resolveProvider': False, 'triggerCharacters': ['.'], 'documentSelector': [{'pattern': '**/*.cs'}, {'pattern': '**/*.csx'}]}, 'method': 'textDocument/completion'}]}

(OmniSharp could register different completion trigger chars for different kinds of files, but it doesn't do that for some reason).

[rwols]

Some initial problems:

The built-in fnmatch library can do "glob" pattern matching, but these items from the LSP spec are not supported:
1) ** (match anything recursively)
2) {foo,bar} brace expansion

[rchl]

I've also been dealing with this for the file watching prototype.

fnmatch is not doing a glob matching but Unix shell-style matching.

I'm not sure if there is a built-in python module that can match a glob against a path. There is https://docs.python.org/3/library/glob.html but that finds the files on disk that match the glob.

[rchl]

Maybe this would work: https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.match ?

There is a ST dependency for pathlib.

[rwols]

Actually this wcmatch library from @facelessuser seems exactly what we need :) https://github.com/facelessuser/wcmatch but it's not an ST library it seems.

[rwols]

Another problem is that the get_capability and has_capability methods from Session will need an extra view argument (a sublime.View), because a server can register itself as e.g. a completionProvider for files of type X, but not for files of type Y.

[facelessuser]

If wcmatch is strongly desired, once I get the 7.0 release of wcmatch out out (should be today or tomorrow), I can refresh myself on how difficult it is to bring back py33 support. I don't think it is much.

If you guys are serious about about it, create an issue over at wcmatch so I don't forget.

[facelessuser]

Just an FYI, with minimal changes I was able to get wcmatch up and running:

Python 3.3>>> from FileSearch.wcmatch import glob
Python 3.3>>> glob.globmatch('BracketHighlighter/bh_modules/bracketremove.py', '**/*.py', flags=glob.GLOBSTAR)
True

So, this looks like it will be a viable option if desired.