kate lsp client plugin

Christoph Cullmann christoph at cullmann.io
Mon Jul 8 22:04:55 BST 2019


>> 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).


Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

More information about the KWrite-Devel mailing list