kate lsp client plugin

[Dominik Haumann]

Hi Mark,

there are currently 2 review requests for the lsp plugin:
- https://phabricator.kde.org/D22348
- https://phabricator.kde.org/D22349

You may want to create a phabricator account so that you can do reviews
here as well.
If you think these changes look good, please "Approve" them.

Best regards
Dominik



On Tue, Jul 9, 2019 at 10:06 PM Mark Nauwelaerts <mark.nauwelaerts at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20190709/1a341617/attachment-0001.html>