<div dir="ltr"><div>Hi Mark,</div><div><br></div><div>there are currently 2 review requests for the lsp plugin:</div>- <a href="https://phabricator.kde.org/D22348">https://phabricator.kde.org/D22348</a><div><div>- <a href="https://phabricator.kde.org/D22349">https://phabricator.kde.org/D22349</a></div><div><br></div><div>You may want to create a phabricator account so that you can do reviews here as well.</div><div>If you think these changes look good, please "Approve" them.</div><div><br></div><div>Best regards</div><div>Dominik</div><div><br></div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2019 at 10:06 PM Mark Nauwelaerts <<a href="mailto:mark.nauwelaerts@gmail.com">mark.nauwelaerts@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 08/07/19 23:04, Christoph Cullmann wrote:<br>
> Hi,<br>
><br>
>>> The changes were fortunately sufficiently separated, so the merge<br>
>>> worked out fairly well (and I did not have to do the parsing code<br>
>>> anymore ;-) ).  Incorporating/combining the "highlight" highlighting<br>
>>> (minor pun) into that of the other calls (along with marking) should<br>
>>> now not be so difficult and will be finished soon-ish.<br>
>><br>
>> :=) Nice that I didn't cause you too much work.<br>
>><br>
>>><br>
>>> Thanks for the advertising, that's one of my (many) not so strong<br>
>>> points, so if someone handles that then ...<br>
>><br>
>> If all I have to do is write some blog posts, this is no problem.<br>
>> Just keep the nice patches coming.<br>
>><br>
>> I "presented" the current state at work today, at least my Kate using colleague<br>
>> was impressed what already "works" at the moment :=)<br>
><br>
> something that might be interesting for the plugin API:<br>
><br>
> At the moment, there might be unwanted changes to the document between sending <br>
> its<br>
> state and receiving the answer back leading to 'wrong' applications of e.g. <br>
> highlighting<br>
> and jump positions.<br>
><br>
> For this, the MovingInterface provides some "lockRevision".... concept, that one<br>
> can lock a document revision, send the data of that and later translate the <br>
> cursor/ranges<br>
> based on the old state.<br>
><br>
> This could be used for the symbol outline, too, to still jump to at least <br>
> "more right" position<br>
> even after editings.<br>
><br>
> For my highlight callback I tagged the lamba with some QPointer to the view, <br>
> perhaps<br>
> even some more generic "tag each request with a QPointer to a view if wanted" <br>
> might make sense,<br>
> too, then some "is this still the right view" checks are easier (and safer for <br>
> the "view got deleted" case).<br>
><br>
> Greetings<br>
> Christoph<br>
><br>
Interesting ...  at present the "servermanager" sends a (meaningless) document <br>
revision-id to the server, but it may well send a revision obtained from <br>
MovingInterface (and lock as well). Some simple RAII wrapper (with shared <br>
semantics) can be made for a "locked revision" and a collection of those (for <br>
current known/tracked documents) returned from servermananger to caller (when <br>
requesting a document sync/update to the server).  That (RAII) collection can <br>
then be captured into the lambda (if so deemed desired/useful by caller) so that <br>
the (old) revision is available for translation to current(cursor positions) <br>
when processing response.  Shared RAII will then release as and when ok by all <br>
holders.<br>
<br>
In case of symbolview, that is probably not needed, since the outline is a <br>
"moving target" anyway when typing frantically and will update (accurately) to <br>
latest state when typing seizes.<br>
<br>
However, it is as noted useful for well-aimed highlighting, and also when the <br>
time comes for processing server TextEdits (e.g. formatting).<br>
<br>
Regards,<br>
Mark<br>
</blockquote></div>