I got RLS working with Atom using atom-languageclient.
Unfortunately, it doesn’t work out of the box. Out of the box, it doesn’t even load! This is strange, because after fixing loading issues which are shallow, it worked great. So it must be working for the author.
A small note regarding indexing/compiling.
I am currently using CLion on a sizeable codebase, when doing git pull --rebase CLion needs to update its indices which takes some time because of said size, which is understandable.
The really annoying part, however, is that while the update is ongoing the indices are unusable.
Please, please, keep two sets of indices in RLS: the last complete one, and the one being rebuilt.
Not only does it give a better user experience, but it also means that the speed at which you rebuild matters less (since probably not that much actually changed).
This is also important to be able to continue offering type information (about the remaining, unaffected things) if the code is edited and now contains a type error, isn't it? It's what the Haskell analogues do as far as I'm aware.
Yep, we do this
I wonder how you plan to solve this problem.
Yeah, this is a hard problem and we don't have a solid plan. It is on our minds though.
Maybe the compiler should gain to ability to output only the metadata (.rmeta file ??) instead of a full .rlib ?
It already can (-Zno-trans), we use this in the RLS but that is the reason it struggles with syntax extensions. We plan to add better support to the compiler and Cargo in the very near future to avoid this problem.
Thanks for the info, I filed an issue to make an Eclipse Che agent. Hopefully, we’ll have something created soon!
Hm, I don't think so. To deal with errors (and most of the time they are syntax errors), you need to be lax in your typehcecking. For example, when checking a function call you always give the return type as the result, without looking at the argument's types (or quantity). For if, you don't unify branches and just return the type of the first branch which has a valid type.
Type inference is mostly a local affair, so you don't need indices much, as it is cheap just to recalculate it for the currently open files. Indices are used mostly (at least in IntelliJ) for finding stuff in other files, that is, for non local things.
Fantastic - I think longer term, there is not a consistent way that language servers should be packaged for different projects. There is a long thread on the language server repository about this where the Microsoft engineers want to use NPM to package a language server, but we are resisting that idea. We dynanically install language servers into workspaces that are containers which can have any OS, so we look for POSIX compliance. One idea is to have language servers package themselves into Dockerfiles which can be launched consistently by any tool. And then the tool would be responsible for hooking up the container with the project files in a workspace.
We would then like to have an open source registry hosted at the foundation for eclipse where language servers can list themselves, update themselves, and let any tool have discovery automatically.
I’m really excited to see the amazing work in the direction of editor independent tooling 
My only concern: I hope the good tooling support would not be used as a justification of not fixing the weaknesses of the language. That’s the trap Java fell into. E.g., people are tolerating lots of unnecessary boilerplate because of IDEs.
I translated your article into Chinese. https://mp.weixin.qq.com/s?__biz=MzIwNjQ2NjI4NA==&mid=2247483891&idx=1&sn=c96158022dd835d19965572437967316&chksm=97207c70a057f5668d1b1a8985dd7f0dc777ac6b65ff74a97d4655cf82ff7841cf28339e8737&scene=0#rd
Did you guys started to work on it? Do you think now that emacs supports "shared/dynamic libraries" that the package could be written in Rust?
Did you guys started to work on it?
Yes. GitHub - sourcegraph/emacs-lsp: LSP support for Emacs. It'll be pretty much complete by 2016-11-11, the current status is not quite ready 
Do you think now that emacs supports "shared/dynamic libraries" that the package could be written in Rust?
No, I don't think that makes any sense at all.
Nice! 
Why (I'm not arguing, I'm just curious, that information could be useful one day)? Is it because modules needs to be compiled with emacs making them a pain to use?
Any update?
It has basic support for a few methods: hover, definition, references, and symbol search. I haven't tested it with the RLS yet. I'll be adding support for the additional methods supported by the RLS over the next few days.
RE: compiled emacs plugin, it doesn't make sense in that the benefits of Rust are pretty much non-existent and the cost of integration with elisp is too high. As you mention it also does complicate deployment.
FYI, another Emacs package has popped up:
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.