kate lsp client plugin

[Olivier Goffart]

Hi Mark,

Thanks for contributing this plugin, I have been trying it with the rust LSP 
and it works fine. (after i made the two small changes)


It was a bit strange to figure out the .json file. So i guess some better UI 
for that would be nice.

Here is what i have for rust

        "Rust":
         {
             "command": 
"/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rls",
             "root": "/home/user/path/to/project"
         }


The problem is that the root folder must be the folder containing the 
"Cargo.toml"  file.
When there are several crates open at once, it is different for every crates.
I'm not sure how this is supposed to be fixed.


On 09.07.19 22:10, Dominik Haumann wrote:
> 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 
> <mailto: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
>