Mika Vilpas

Hehe, nice! :D @nosami do you think this could BE a useful hack to have on the server side BT default? At least until omnisharp-roslyn is released, if you can...

Also had this idea: show alternative overloads. We cache the last auto-complete response (in omnisharp--last-buffer-specific-auto-complete-result - a buffer-local variable), and could add a function to also cache the last chosen...

For the bolding to work, we also have to save the chosen overload into a buffer-local variable. This needs to be done in all auto-complete backend functions.

:+1: What do you think, would eldoc suffice? We display current type information with eldoc. On the other hand, for example lispy goes the extra step and displays stuff like...

Ah I see what you mean. Eldoc is clearly out of the question. I haven't really looked at the server api yet. 2016-05-11 1:12 GMT+03:00 jtbm37 [email protected]: > I am...

This is exciting! Let's keep an eye on that. I wonder if the completion API will change, or if it's just going to be an internal change with no visible...


Maybe this endpoint could help you: https://github.com/OmniSharp/omnisharp-server/blob/master/OmniSharp/UpdateBuffer/UpdateBufferModule.cs I don't think we have a way of using it. You can create a new one, just experiment with a simple omnisharp-emacs function...

I can take a look at this later on.

Ended up rolling my own (in javascript). It looks like this: ```js export function called(expecting) { return defineCombinator((source) => { return new (class Called extends ParjserBase { type = "called";...