<div dir="auto">Hi Mark,<div dir="auto"><br></div><div dir="auto">the current version does not work anymore for me. Is there anything that I need to pay attention to?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto">Dominik</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Mark Nauwelaerts <<a href="mailto:mark.nauwelaerts@gmail.com">mark.nauwelaerts@gmail.com</a>> schrieb am Mi., 10. Juli 2019, 19:04:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/07/19 16:28, Christoph Cullmann wrote:<br>
> Hi,<br>
><br>
>> Interesting ...  at present the "servermanager" sends a (meaningless)<br>
>> document revision-id to the server, but it may well send a revision<br>
>> obtained from MovingInterface (and lock as well). Some simple RAII<br>
>> wrapper (with shared semantics) can be made for a "locked revision"<br>
>> and a collection of those (for current known/tracked documents)<br>
>> returned from servermananger to caller (when requesting a document<br>
>> sync/update to the server).  That (RAII) collection can then be<br>
>> captured into the lambda (if so deemed desired/useful by caller) so<br>
>> that the (old) revision is available for translation to current(cursor<br>
>> positions) when processing response.  Shared RAII will then release as<br>
>> and when ok by all holders.<br>
>><br>
>> In case of symbolview, that is probably not needed, since the outline<br>
>> is a "moving target" anyway when typing frantically and will update<br>
>> (accurately) to latest state when typing seizes.<br>
><br>
> Hmm, I think for the symbol view it would be not that bad, given at least <br>
> normally<br>
> it will perfectly fine translate the line moves and you don't need to trigger <br>
> reparsing<br>
> that often at all. But it is nothing critical.<br>
><br>
>><br>
>> However, it is as noted useful for well-aimed highlighting, and also<br>
>> when the time comes for processing server TextEdits (e.g. formatting).<br>
><br>
> Yes, for that it would be much more important.<br>
><br>
> Dominik linked you some pull requests for some smaller changes, you could take <br>
> a look at that.<br>
><br>
> If you have some further changes, it would be cool if you can push them,<br>
> I want to take a look if I could improve the highlight further ;=)<br>
><br>
> Greetings<br>
> Christoph<br>
><br>
>><br>
>> Regards,<br>
>> Mark<br>
><br>
Ok, I pushed all I have here (specifically the highlight stuff).<br>
<br>
I had a look at those requests and accepted them, which turned into Approved for <br>
one of them, but not so for the other (in a more confused state?).  I assume the <br>
actual landing is then done by back-end and/or submitting author?<br>
<br>
Regards,<br>
Mark.<br>
</blockquote></div>