mark.nauwelaerts at gmail.com
Sat Aug 10 20:18:05 BST 2019
On 10/08/19 17:40, Christoph Cullmann wrote:
>> 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:
> 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
> 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
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).
More information about the KWrite-Devel