kate lsp client plugin

[Mark Nauwelaerts]

On 08/07/19 23:04, Christoph Cullmann wrote:
> Hi,
>
>>> The changes were fortunately sufficiently separated, so the merge
>>> worked out fairly well (and I did not have to do the parsing code
>>> anymore ;-) ).  Incorporating/combining the "highlight" highlighting
>>> (minor pun) into that of the other calls (along with marking) should
>>> now not be so difficult and will be finished soon-ish.
>>
>> :=) Nice that I didn't cause you too much work.
>>
>>>
>>> Thanks for the advertising, that's one of my (many) not so strong
>>> points, so if someone handles that then ...
>>
>> If all I have to do is write some blog posts, this is no problem.
>> Just keep the nice patches coming.
>>
>> I "presented" the current state at work today, at least my Kate using colleague
>> was impressed what already "works" at the moment :=)
>
> something that might be interesting for the plugin API:
>
> At the moment, there might be unwanted changes to the document between sending 
> its
> state and receiving the answer back leading to 'wrong' applications of e.g. 
> highlighting
> and jump positions.
>
> For this, the MovingInterface provides some "lockRevision".... concept, that one
> can lock a document revision, send the data of that and later translate the 
> cursor/ranges
> based on the old state.
>
> This could be used for the symbol outline, too, to still jump to at least 
> "more right" position
> even after editings.
>
> For my highlight callback I tagged the lamba with some QPointer to the view, 
> perhaps
> even some more generic "tag each request with a QPointer to a view if wanted" 
> might make sense,
> too, then some "is this still the right view" checks are easier (and safer for 
> the "view got deleted" case).
>
> Greetings
> Christoph
>
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.

However, it is as noted useful for well-aimed highlighting, and also when the 
time comes for processing server TextEdits (e.g. formatting).

Regards,
Mark