kate lsp client plugin
Mark Nauwelaerts
mark.nauwelaerts at gmail.com
Fri Jul 12 18:25:40 BST 2019
Hi Dominik,
For "Goto Declaration", this is actually "normal" and that also happens here.
That is because a (slightly older) clangd does not support that method, as
reported in the (error) reply. Unfortunately there is no (spec'ed) way to detect
that client-side, which is why the action is still enabled. So as long as "Goto
Definition" and the others still work, then it is about as OK as it can be ...
More generally, there will always be some cases where the server does not handle
something in some way, and where it may feel that is due to kate/lspclient. In
this case it might be detected by the error reply but there are other cases as
well. For instance, the "includeDeclaration" (for Find References) is
checkable, but neither clangd nor python-language-server consider that setting
(when translated to protocol level), and so the result of "Find References" will
be the same whether or not enabled ... So no way at all to detect that, which
is why I was considering disabling that configuration option, but then again
other servers might properly support it (or also clangd in some time) ...
The "Failed to find compilation database" part that clangd reports might also be
a bit worrying here, but may or may not be relevant ...
Regards,
Mark
On 12/07/19 09:12, Dominik Haumann wrote:
> Hi Mark,
>
> indeed the code completion is also working - my bad, sorry.
> For "Goto Declaration", I can see the following output on the console:
>
> LSPClientServer::LSPClientServerPrivate::write: calling "textDocument/didChange"
> LSPClientServer::LSPClientServerPrivate::write: calling "textDocument/declaration"
> V[09:08:39.475] <<< { "jsonrpc":"2.0","method":"textDocument/didChange",
> "params":{
> "contentChanges":[{"text":" <stripped documents contents>"}],
> "textDocument":{"uri":"file:///home/dh/kde/kf5/src/kde/applications/kate/addons/lspclient/lspclientserver.cpp","version":9}
> }
> }
>
> I[09:08:39.550] <-- textDocument/didChange
> I[09:08:39.550] Failed to find compilation database for
> /home/dh/kde/kf5/src/kde/applications/kate/addons/lspclient/lspclientserver.cpp
> V[09:08:39.550] <<<
> {"id":11,"jsonrpc":"2.0","method":"textDocument/declaration","params":{"position":{"character":22,"line":155},"textDocument":{"uri":"file:///home/dh/kde/kf5/src/kde/applications/kate/addons/lspclient/lspclientserver.cpp"}}}
>
> I[09:08:39.551] <-- textDocument/declaration(11)
> I[09:08:39.551] --> reply:textDocument/declaration(11) 0 ms, error: -32601:
> method not found
> V[09:08:39.551] >>> {"error":{"code":-32601,"message":"method not
> found"},"id":11,"jsonrpc":"2.0"}
>
> Maybe that helps in identifying the issue :-)
>
> Best regards
> Dominik
>
>
>
>
> On Thu, Jul 11, 2019 at 10:52 PM Mark Nauwelaerts <mark.nauwelaerts at gmail.com
> <mailto:mark.nauwelaerts at gmail.com>> wrote:
>
> Hi Dominik,
>
> Rather puzzling ... I suppose the message is "No results". There have
> been a few changes there, but those are mostly related to post-processing
> of the results (to display in a bottom toolview), or displaying that
> message if nothing found. There have been no changes in the part leading
> up to getting the result. It does all still work here ... does completion
> still work?
>
> Running kate with debug might shed some more light whether the request to
> server is bogus, or the server has somehow given up on coming up with results;
> QT_LOGGING_RULES=katelspclient.debug=true ./bin/kate 2>/tmp/output.log
>
> Regards,
> Mark
>
> On 11/07/19 22:25, Dominik Haumann wrote:
>> Hi Mark,
>>
>> the current version does not work anymore for me. Is there anything that
>> I need to pay attention to?
>>
>> The symbols sidebar still works, but all other actions that operate on
>> the current cursor position just result in a Message in the bottom right
>> corner.
>>
>> Best regards
>> Dominik
>>
>> Mark Nauwelaerts <mark.nauwelaerts at gmail.com
>> <mailto:mark.nauwelaerts at gmail.com>> schrieb am Mi., 10. Juli 2019, 19:04:
>>
>> On 10/07/19 16:28, Christoph Cullmann wrote:
>> > Hi,
>> >
>> >> Interesting ... at present the "servermanager" sends a (meaningless)
>> >> document revision-id to the server, but it may well send a revision
>> >> obtained from MovingInterface (and lock as well). Some simple RAII
>> >> wrapper (with shared semantics) can be made for a "locked revision"
>> >> and a collection of those (for current known/tracked documents)
>> >> returned from servermananger to caller (when requesting a document
>> >> sync/update to the server). That (RAII) collection can then be
>> >> captured into the lambda (if so deemed desired/useful by caller) so
>> >> that the (old) revision is available for translation to current(cursor
>> >> positions) when processing response. Shared RAII will then release as
>> >> and when ok by all holders.
>> >>
>> >> In case of symbolview, that is probably not needed, since the outline
>> >> is a "moving target" anyway when typing frantically and will update
>> >> (accurately) to latest state when typing seizes.
>> >
>> > Hmm, I think for the symbol view it would be not that bad, given at
>> least
>> > normally
>> > it will perfectly fine translate the line moves and you don't need
>> to trigger
>> > reparsing
>> > that often at all. But it is nothing critical.
>> >
>> >>
>> >> However, it is as noted useful for well-aimed highlighting, and also
>> >> when the time comes for processing server TextEdits (e.g. formatting).
>> >
>> > Yes, for that it would be much more important.
>> >
>> > Dominik linked you some pull requests for some smaller changes, you
>> could take
>> > a look at that.
>> >
>> > If you have some further changes, it would be cool if you can push
>> them,
>> > I want to take a look if I could improve the highlight further ;=)
>> >
>> > Greetings
>> > Christoph
>> >
>> >>
>> >> Regards,
>> >> Mark
>> >
>> Ok, I pushed all I have here (specifically the highlight stuff).
>>
>> I had a look at those requests and accepted them, which turned into
>> Approved for
>> one of them, but not so for the other (in a more confused state?). I
>> assume the
>> actual landing is then done by back-end and/or submitting author?
>>
>> Regards,
>> Mark.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20190712/455f11a5/attachment.html>
More information about the KWrite-Devel
mailing list