Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Kate editor #1521

Open
dhardy opened this issue Jul 23, 2019 · 24 comments

Comments

@dhardy
Copy link

commented Jul 23, 2019

Any other Kate + Rust users?

The Kate editor has initial LSP support. It would be nice to have Rust LSP support (mention #87).

@Xanewok

This comment has been minimized.

Copy link
Member

commented Aug 2, 2019

That'd be great, yeah! RLS is a standard LSP server which communicates over stdio so everything should just work plug-and-play style. Do you have contact with Kate developers? It'd be great to discuss potential inclusion of Rust support.

@dhardy

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

I believe @christoph-cullmann has been working on the LSP support within Kate. Yes, having Kate+RLS support would be great (#343 approaches this from a different angle for KDevelop, but I believe that has not been maintained).

Myself, I got as far as compiling the dev branch and configuring Kate to use RLS, but the only evidence of success was an init message.

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 6, 2019

Hi ;)

At the moment, there is a fixed list of default supported LSP servers in the addons/lspclient/lspclientservermanager.cpp file in kate.git, see line 536...

If you tell me what the standard invocation of rls looks like, we can add it there.

@Xanewok

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

For the context: https://github.com/KDE/kate/blob/54843cd1eaf346181f7a42596baf37715a261618/addons/lspclient/lspclientservermanager.cpp#L536-L547 and how VS Code extension spawns the process: link

I think just calling rls would be good - that's a standard invocation and if rustup toolchain manager is used then it automatically symlinks the shim binary to the actual one used by the currently selected toolchain (One can also use specific toolchain via rustup run <TOOLCHAIN> rls).

In general it should be working-directory-agnostic but IIRC rustup supports local toolchain override and for that to work correctly I believe the process should be spawned with working directory set to the Rust project/Kate workspace root so the rustup can pick up the override file.

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 6, 2019

Hmm, just starting rls doesn't seem to do the trick for me.
Does it only search for the Cargo.toml based on it's startup directory but not based on the location of the file you feed to it?

e.g. just adding some

,
{ QStringLiteral("Rust"),
makeServerConfig(QStringLiteral("rls")) }

entry to the above code in Kate does lead to a started rls for Rust files but it doesn't seem to pick up any sensible config.

@Xanewok

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

It relies on the root{Path,Uri} parameter passed in LSP initialize request - it should then scan for Cargo.toml for the directory for which it was initialized.

@nrc nrc referenced this issue Aug 6, 2019
8 of 12 tasks complete
@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 6, 2019

That means for e.g. Kate: We should scan for a Cargo.toml (or try to derive the project root on our own) and init the LSP server with the directory we find?

@Xanewok

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

Ah, yeah. Right now RLS works best if you can directly initialize it in a project root with Cargo.toml (whether it's a Cargo workspace or a single package).

I'd like to work on a coordinator-style process, which would try to infer the subprojects from the rough FS layout and possibly spawn relevant sub-processes there, but that's not implemented in the RLS yet.

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 6, 2019

Ok, my first try for this is now here:

https://phabricator.kde.org/D22963

This will try to auto-detect some useful root path and startup rls.
This still can be overwritten with either a global config from the settings or some local lspclient json part in a .kateproject.

Rust developers are welcome to test this, my Rust skills are likely negative ;=)

@dhardy

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

Great, I'll give it a try!

I'm not familiar with phabricator, is there some git url I can pull from?

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 6, 2019

I guess the easiest way without using the arc tooling is just downloading the raw patch

https://phabricator.kde.org/file/data/n7kqrbc57ty3eimwkduy/PHID-FILE-57l5ktnbo76ivifufwfb/D22963.diff

and applying that one.

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 7, 2019

I merged my current version into kate.git master, feel free to try it.

@dhardy

This comment has been minimized.

Copy link
Author

commented Aug 8, 2019

Sorry, I'm not having much luck so far! Without proving my own LSP config file, it seems nothing happens for Rust files (though LSP works on .cpp sources). With my own config (though it should be equivalent) it seems rls gets started but fails to get the right Cargo.toml:

[2019-08-08T08:54:15Z INFO  rls::actions] loading cargo project model
[2019-08-08T08:54:15Z TRACE cargo::util::toml] read_manifest; path=/home/dhardy/Cargo.toml; source-id=/home/dhardy
[2019-08-08T08:54:15Z TRACE cargo::util::errors] error: No such file or directory (os error 2)
[2019-08-08T08:54:15Z TRACE cargo::util::errors]        context: failed to read `/home/dhardy/Cargo.toml`
[2019-08-08T08:54:15Z ERROR rls::actions] failed to fetch project model, using fallback: failed to read `/home/dhardy/Cargo.toml`

From what @Xanewok said earlier, it sounds like rls expects to be started once for each project (Cargo.toml), in that directory. Instead it looks like you're starting rls once in the home dir?

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 8, 2019

Hmm, with my latest patches, exactly that should happen.
It should search upwards for the Cargo.lock (or if non found Cargo.toml) and set that as root and start the rls in that directory.
You can see more details if you start kate with the env

LSPCLIENT_DEBUG=1

@dhardy

This comment has been minimized.

Copy link
Author

commented Aug 8, 2019

Looks to me like rls gets started only once, from my home dir, before it gets any document-specific stuff. (Note that this Kate session has a lot of files open, so the home dir may well be the largest common path.) Using latest git master.

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 8, 2019

Hmm, is that kate.git master?
master outputs now the root the server is started with like:

katelspclientplugin: starting ("clangd", "-log=verbose", "--background-index") with root QUrl("file:///home/cullmann")

But your output has only

katelspclientplugin: starting ("rls")

which is strange. There is no condition to skip that output in master.

@dhardy

This comment has been minimized.

Copy link
Author

commented Aug 8, 2019

$ git remote -v
origin  git://anongit.kde.org/kate (fetch)
origin  git://anongit.kde.org/kate (push)
$ git pull
Already up to date.
@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 8, 2019

Hmm, is anon git lacking behind?

Have you this commit:

https://cgit.kde.org/kate.git/commit/?id=9838d5decb94034535e2433213bcdd902650e9ba

@dhardy

This comment has been minimized.

Copy link
Author

commented Aug 8, 2019

Yes. Head is 09427e8cde8782bbc5d75929304234669ac98828.

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 8, 2019

Hmm, are you sure you execute the right instance?
As you can see in the commit, the output was altered to always print at least "with root".
Do you do make install & execute in the env that the "prefix.sh" script creates like described on https://kate-editor.org/build-it/ ?

@dhardy

This comment has been minimized.

Copy link
Author

commented Aug 8, 2019

Aha, I did indeed skip the make install step!

Now a lot of stuff works, though the document outline is empty for some documents (but present for others). Edit: for many documents, at least when browsing fast. Does the list get refreshed once rls is done scanning?

Seems it takes a while to scan everything; it would be nice if these messages could be used to update the GUI somehow:

discarding notification "window/progress"
@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 8, 2019

:=) The LSP client for sure has room for improvements, contributions welcome ;=)

@Xanewok Xanewok added the clients label Aug 13, 2019

@Xanewok

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

If I understand correctly, this means that Rust support has landed in Kate master? What is the release process? When are the changes going to be released? Can I close this issue now?

@christoph-cullmann

This comment has been minimized.

Copy link

commented Aug 13, 2019

Support is in kate.git master and will ship with KDE Applications 19.12.

If somebody wants to improve the current state, feel free to submit patches at

https://invent.kde.org/kde/kate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.