kate lsp client plugin

[Mark Nauwelaerts]

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/20190711/c458d21b/attachment.html>