Hi,

One correction below.

On Fri, Apr 15, 2022 at 8:12 AM Yegappan Lakshmanan <[email protected]> wrote:
>
> Hi,
>
> On Thu, Apr 14, 2022 at 10:34 PM Prabir Shrestha <[email protected]> 
> wrote:
>>
>> I'm able to download the latest version of vim with lsp support on Windows. 
>> Thanks for the quick fix. ArchLinux vim also seems to be updated to include 
>> this patch. Looking forward to seeing plugin authors use this feature.
>>
>> I have started adding support for native lsp client in vim-lsp and I'm very 
>> happy with the simplicity and ease of use of the api.
>
>
> Thanks for the feedback.
>
>>
>> I have just got basic request/response working so this feedback is a bit 
>> limited while playing with the api for several mins.
>>
>> LSP support $/cancelRequest which requires sending the request id. This is 
>> heavily used by vim-lsp in order to cancel previous requests such as 
>> completion results that could had changed, highlighting current keyword that 
>> could had changed due to the cursor movements. Doc explicitly says Note that 
>> in the request message the 'id' field should not be specified. Is it 
>> possible to have an api to either set the id or get the id of the request?
>
>
> Are you using the ch_evalexpr() function or the ch_sendexpr() function to 
> send the original request?
> If you are using the ch_sendexpr() function, then you can specify an 
> identifier in the message. Vim will
> not modify the identifier. If you are using the ch_evalexpr() function, then 
> Vim will return only when the
>

With the ch_sendexpr() function, if you specify a 'callback' function,
then Vim will use an
internally generated 'id' value and will overwrite the caller supplied
'id'. Currently there is
no support for getting the 'id' value used by the ch_sendexpr()
function. I think we can
return the 'id' value used if a callback function is specified.

- Yegappan

>
> response message is received or the request times out. So you cannot cancel a 
> request sent
> using the ch_evalexpr() function.
>
>>
>> Is it possible to document what resp is in the example doc. let resp = 
>> ch_evalexpr(ch, req, #{timeout: 100}). I also see this being used in the 
>> test and it checks for empty object. I thought this was the request id but 
>> always seem to be empty during my limited test. Probably this only makes 
>> sense for synchronous request? It would still be good to document that it 
>> will always be empty for async as it created a bit confusion to me.
>
> The ch_evalexpr() function returns the decoded response message returned by 
> the server
> for the request message. In the test_channel.vim file, you will see a few 
> examples for
> this (e.g.around line 2540). The ch_sendexpr() function always returns an 
> empty string.
> I will update the help text to describe this.
>
>> Minor: Should the doc include the full raw request? {'jsonrpc': '2.0', 'id': 
>> 1, 'result': { ...}}. I see this as useful doc when writing remote LSP/Json 
>> RPC plugins.
>
>
> Yes.
>
>>
>> It took be a bit to figure out the callback args for ch_evalexpr but seems 
>> like this is already documented at the end where it says to refer to 
>> |channel-callback|. One thing that wasn't clear is if there is a JSON RPC 
>> Error Message would it still call the callback function? Clarifying that 
>> caller needs to handle the message whether it is success or error rpc 
>> messages would be better here. In the future I can see having on_success and 
>> on_error callbacks. I don't see me using this in vim-lsp but do see it using 
>> in other plugins. https://www.jsonrpc.org/specification#response_object
>
>
> The callback function will be called for a JSON RPC error also. So it will be 
> called for both success and error.
> I will update the doc to clarify this.
>
>>
>> Can the sync and async method be used on the same channel?
>
>
> Yes. You can use the ch_evalexpr(), ch_sendexpr() and ch_sendraw() functions 
> on the same
> channel.
>
>>
>> Because vim doesn't support async BufWritePre we recommend users to use the 
>> following code to auto format on save. While 99% of the code will be using 
>> async function there will be sync methods for writing.
>>
>> let g:lsp_format_sync_timeout = 1000
>> autocmd! BufWritePre *.rs,*.go call execute('LspDocumentFormatSync')
>>
>> Is it possible to document the behavior of how to handle timeouts? When 
>> using let resp = ch_evalexpr(ch, req, #{timeout: 100}) what error is thrown 
>> and what error should I handle?
>>
>>
> In the case of a timeout, an empty string will be returned. There won't be 
> any error messages.
> I will update the doc.
>
> Thanks,
> Yegappan
>

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAAW7x7n3yCDvyjC2iiE6%2BAppZ_42sPKTLXdY1womjNyaLzHrwA%40mail.gmail.com.

Raspunde prin e-mail lui