Well, bearing in mind the limitations of my Go, I think what it is telling you is that the Mutex needs to be accessed via pointer, all users of a Mutex must access the same memory, they can't be separate instances. And thats how the docs present it here

I'm a go user myself and I know what that means - and as I said, this representation is more idiomatic than what we show using our TM ctags parser.

But this wasn't my point - my point (including the python and c++ example) was that we cannot be sure what we get from the language server because (*Mutex).Lock isn't a "correct" name in the sense of TM where name would be just Lock and Mutex its scope (which isn't completely correct from the go language point of view because Lock is outside the scope of Mutex). Similarly some language servers will return local symbols, some not and we won't know which ones do and we won't know which tags are local. Etc. The only thing we can do is display them as they are without trying to "understand them", because we can't.

We can't unify them, full stop.

Then we are on the same boat :-).

Perhaps a better way would be to consider if the LSP functions can be available to plugins, but then the asynchronicity might be a problem.

Technically they could be, plugins would have to deal with the asynchronicity somehow (I think it wouldn't be a big deal) but the question is whether they can do anything useful with them (or in other words, if they can do something useful, whether such feature shouldn't be part of the LSP plugin itself). I for instance don't know what plugins could do with calls like autocompletion or goto tag definition. The symbol list of the current document is the only one possibly useful if they want to display the symbols differently as Thomas suggested, but even this one is a bit iffy when we can't be sure about the exact format of the symbols.

How do you handle multiple plugins trying to provide the same function?

The "first" plugin providing the functionality would win. So for instance the plugin returning TRUE for autocomplete_available(doc) would be used for the autocompletion of the given doc's filetype. The "first" is in quotes because it would depend on some internal ordering depending how plugins were loaded - but basically the intended usage would be to have each plugin for a different filetype so they wouldn't overlap, otherwise the "winning" plugin would be undefined.

Anyway, this isn't something important, I just mentioned it because the current interface is of this kind already, only the implementation supports a single plugin, but that could be changed easily.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.