lspclient update

[Mark Nauwelaerts]

On 10/08/19 17:40, Christoph Cullmann wrote:
> Hi,
>
>> Will try if I can add some more server configs.
>
> during playing bit more with rls for Rust I discovered we didn't support
> all kind of hover responses, I fixed that now in:
>
> https://invent.kde.org/kde/kate/commit/c54497958615c5e8fff1388e0ec89a266c9328c4
>
> This allows hover to work for rls, too.
>
> The displaying as tooltip is problematic for large content including a lot of
> documentation, to avoid that you full screen is hidden by the tooltip I now 
> hard-cut
> it after some limit.
>
> We would need some better hover widget for that ;=)
>
Indeed, and thanks, missed out on that part before as some implicit TODO.

I pushed a few commits that now optionally enables incremental document sync (to 
server), as opposed to always sending the whole document.  The latter is still 
the default, as it is most simple/reliable and has not given any problems so 
far.  But maybe in some cases the incremental might be useful when dealing with 
large documents.

There is still something else to (really) enable in this area (document 
changes).  The RevisionGuard is in place to "lock" old revision (using 
MovingInterface), to pass this along to a server call and then use the old 
revision to translate ranges (wrt old revision) to current one (as there may 
have been changes in the meantime).  However, as I see/understand it (and so 
documented), even when locked, an old revision might still get invalidated (e.g. 
when a clear() happens in katetexthistory.cpp.  Also, however, it is not certain 
(or evident) if/how to detect that this happens.  Is it guaranteed that (e.g.) 
aboutToInvalidateMovingInterfaceContent will be emitted if such a clear() occurs 
(or anything that might invalidate even locked revisions)?  Since using a 
revision in transform (or unlock) calls that is no longer valid will trigger 
unfortunate asserts (or other things if assert disabled).

Regards,
Mark.