LanguageClient-neovim
LanguageClient-neovim copied to clipboard
autozimu
Updates
g:LanguageClient_signColumnAlwaysOn was deprecated.
Use set signcolumn=yes instead.
Default g:LanguageClient_diagnosticsDisplay has changed to
{
1: {
"name": "Error",
"texthl": "ALEError",
"signText": "✖",
"signTexthl": "ALEErrorSign",
},
2: {
"name": "Warning",
"texthl": "ALEWarning",
"signText": "⚠",
"signTexthl": "ALEWarningSign",
},
3: {
"name": "Information",
"texthl": "ALEInfo",
"signText": "ℹ",
"signTexthl": "ALEInfoSign",
},
4: {
"name": "Hint",
"texthl": "ALEInfo",
"signText": "➤",
"signTexthl": "ALEInfoSign",
},
}
New Configuration: LanguageClient_windowLogMessageLevel
g:LanguageClient_windowLogMessageLevel *g:LanguageClient_windowLogMessageLevel*
Maximum MessageType to echoshow messages from window/logMessage.
MessageType >
export namespace MessageType {
/**
* An error message.
*/
export const Error = 1;
/**
* A warning message.
*/
export const Warning = 2;
/**
* An information message.
*/
export const Info = 3;
/**
* A log message.
*/
export const Log = 4;
}
Default: "Warning"
Valid options: "Error" | "Warning" | "Info" | "Log"
Announcement and Breaking Changes
Master branch is deprecated. Please switch to branch next if possible. All of the functionalities should behave exactly as previously, only
- more performant and more robust
- better support for vim
- no more dependant on python
File an issue if it isn't the case.
Default branch is set to next. So new installation will be using branch next by default.
This is awesome that you no longer rely on python!
I did notice that you download upon install. That's going to make it hard to use this within certain corporate settings. Is it possible for you to make releases that have the necessary binaries included within them? (Vim Plug allows specifying a branch/release I believe).
The main concern is that committing in binary blobs will explode the repo pretty quickly.
Besides the install script, there are also two alternatives,
- build the repo with
make release - download the corresponding binary manually and place it as
bin/languageclient, which is exactly the same as install script does.
Not sure if this answers your question. And let me know if there are any better solutions.
You can have the master branch download on the fly when you install the master branch, but then you can also publish versions of the plugin that have the prebuilt artifacts inside the repo, in your "releases" page. Vim-plug should also allow depending on releases as well. I think you do so like this:
Plug 'autozimu/LanguageClient-neovim', { 'tag': 'release-1.2.3-bin-darwin' }
That would give corporate users the option of just depending on the tagged release for their platform. I think it would actually be better for most users (even outside of corporate environments)
I did notice that you download upon install. That's going to make it hard to use this within certain corporate settings. Is it possible for you to make releases that have the necessary binaries included within them? (Vim Plug allows specifying a branch/release I believe).
Could someone somewhere explain why there was a switch to the rust solution compared to python? I can imaging some people are also unhappy about downloading "random" binary blobs that they did not verify. Maybe adding a "manual-install.sh" file as an alternative to call in vim-plug etc, which compiles from source, documented in the readme, would also be a nice option.
I would suggest two modes: One that includes prebuilt binaries in the releases page, One that builds them from scratch on the fly upon installation?
Note added to build locally. https://github.com/autozimu/LanguageClient-neovim/commit/379d42eb0b6c8eaab12c234e3ad235fe6312febc
As I mentioned before, if we commit in binary blobs into repo, since every release (combining every platforms) is 20Mb, with 50 releases, they are going to be 1Gb increase of repo size, which I believe is not a practical thing.
You only really need to keep the most recent n releases lying around per platform, right? Github accepts individual artifacts up to 100MB in the repo. We do this for reason-cli for much larger artifacts and it works well. You can create a separate repo just for releases of LanguageClient-neovim if you don't want to have to use special git commands to avoid pulling in large artifacts while developing locally.
It's not possible to delete blobs from the repo once you've pushed them. They stay part of the git history forever.
@tbodt are you sure about that? I believe you can delete their tags, which orphans them. Doesn't github have some kind of a collection process?
@jordwalke not if the commits are still reachable, which they would be if this was done the obvious way
You can push the deletion of a specific tag from the command line, which makes the commits unreachable. Were you aware of that? Doesn't that solve the problem? It's what I've been doing.
I'm aware, but if, say, there was a commit tagged 1.0, and that commit is reachable from master, deleting the tag does nothing.
@jordwalke Can you elaborate on the approach? If there are already binaries, how could I commit them into the main repo without significantly increase .git size?
As far as I understand, artifacts in releases page are separate from main repo.
When you do a release, don't tag the final commit as the release. Instead make a new branch off of the final commit, make a commit to that branch adding the binaries, and then tag that commit and delete the branch.
That way, when you delete the tag, the commit with the binaries is no longer reachable and will be deleted. This is a real pain to manage properly though.
@tbodt Yes, that is how you do it so that master (or any other branch) never has a release in its history. Then deleting old release tags properly orphans them. It's not a pain to manage though. It's just a git command from the command line to delete a tag and push the deletion.
Whenever you tag a commit and push the tag to github, github automatically creates a convenient download link in the releases page that is just a tar/zip at that commit - but with none of the git history. This is what vim-plug should be using when you specify:
Plug 'autozimu/LanguageClient-neovim', { 'tag': 'release-1.2.3-bin-darwin' }
That's how npm dependencies on tags work as well.
Here's how you push a deletion of a remote tag
@tbodt I don't understand what is so difficult about this release workflow. It's not difficult to avoid releases being in master's history - you would really have to go out of your way to put giant build artifacts in master's history.
You'd typically have some script like release.sh 1.2.3 or make release 1.2.3, which runs the build so that the build artifacts appear as if they had been built at the time of installing the plugin, then the release script does something like:
git add allTheArtifacts
git commit -m "release 1.2.3-bin-darwin"
git tag 1.2.3-bin-darwin
git push origin 1.2.3-bin-darwin
(assuming you are on OSX). The tag references a single commit that contains the build artifacts, with the master branch as its parent commit, and master doesn't have 1.2.3-bin-darwin's single commit in its history. That way if you ever need to delete the tag, it will be properly orphaned. This isn't necessarily going out of the way to do releases like this - it's pretty much the process you'd stumble upon without really trying, in my experience.
@jordwalke the problem is that even if this isn't reachable from master you need to download ALL binaries from GitHub even if you do not care about built releases. And let's be honest, what is the difference between downloading random blob via HTTPS using Git and downloading random blob via HTTPS using wget/curl?
The difference is when the download happens. If it is modeled as an actual Plugin dependency then it can be automatically snapshotted easily and uses in corporate environments. If needed you could create a separate repo just for the releases. But even in the worst case this only effects the developers of the plugin because if you depend on a specific GitHub release, GitHub constructs links for them that bypass all git history and only include that single binary for that specific version. Check the tar.gz for reason-cli releases for example.
The recommended installation has changed
-Plug 'autozimu/LanguageClient-neovim', {'tag': 'binary-*-x86_64-apple-darwin' }
+Plug 'autozimu/LanguageClient-neovim', {
+ \ 'branch': 'next',
+ \ 'do': 'install.sh',
+ \ }
The reason is that tagged release doesn't work very well in vim-plug,
- In initial installation, it fetches all tags.
- In
:PlugUpdate, it won't fetch new tags not in current branch.
Note that the tag based installation is still supported by this repo. It’s just not the recommended approach until the mentioned vim-plug issue is fixed.
On Sat, Jan 6, 2018 at 04:34 Jordan W [email protected] wrote:
Sad!
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/autozimu/LanguageClient-neovim/issues/35#issuecomment-355744184, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYt7-Y4ZeHp0oa134R_mp8iwsEZdMaXks5tH2hogaJpZM4MmzQ8 .
I believe so. But that will require update commit SHA manually.
On Sat, Jan 6, 2018 at 15:42 Jordan W [email protected] wrote:
Does specifying a commit work reliably?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/autozimu/LanguageClient-neovim/issues/35#issuecomment-355786682, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYt7-fblgMh5-mmL0HLhwPEK996Iz4eks5tIATggaJpZM4MmzQ8 .
New configuration g:LanguageClient_loggingFile
https://github.com/autozimu/LanguageClient-neovim/blob/9a316ef9f044674724b44cd162f3996113ea4861/doc/LanguageClient.txt#L184-L189
New configuration g:LanguageClient_serverStderr
https://github.com/autozimu/LanguageClient-neovim/blob/e5e44f21ba3fb027676df5619c62caf6e4939a5c/doc/LanguageClient.txt#L198-L203
New configuration g:LanguageClient_diagnosticsSignsMax
https://github.com/autozimu/LanguageClient-neovim/blob/bb733ef7ff87328426cf00ab517495ea45d90cdf/doc/LanguageClient.txt#L108-L113
New function LanguageClient#explainErrorAtPoint to show detailed error under cursor.
https://github.com/autozimu/LanguageClient-neovim/blob/5e968547dea733a25de74c1f9babd9e77459598a/doc/LanguageClient.txt#L553-L556
For the new toggled panel, I suggest incorporating my implementation of panel toggling which does not disrupt the current window positions (in that way it's more like an overlay): https://github.com/jordwalke/VimBox/blob/25cf2ff2a2433804bba724873cd27a4225850af9/dotVim/pluginRc/toggly/togglyVimRc
New function LanguageClient#debugInfo to print out debug info.
https://github.com/autozimu/LanguageClient-neovim/blob/542203b6aa435b93a21e123b2177b18cd1a1a8ed/doc/LanguageClient.txt#L567-L570
Default
g:LanguageClient_diagnosticsDisplayhas changed to{ 1: { "name": "Error", "texthl": "ALEError", "signText": "✖", "signTexthl": "ALEErrorSign", }, 2: { "name": "Warning", "texthl": "ALEWarning", "signText": "⚠", "signTexthl": "ALEWarningSign", }, 3: { "name": "Information", "texthl": "ALEInfo", "signText": "ℹ", "signTexthl": "ALEInfoSign", }, 4: { "name": "Hint", "texthl": "ALEInfo", "signText": "➤", "signTexthl": "ALEInfoSign", }, }
I am trying to setup nvim + LanguageClient-neovim + rls. Overall it seems to work quite good. But in your screenshots I can see that it should be possible to setup nvim, to underline warnings or errors. So far my setup only shows ⚠ or ✖ on the left most column. I am missing the underlined errors, which seems to be valuable information.
rustDocument/implementations was removed #655.
rustDocument/implementationswas removed from rls back in July - at this commit. It now uses the standardtextDocument/implementation.
Event LanguageClientBufReadPost was renamed to LanguageClientTextDocumentDidOpenPost to make it more accurate. @https://github.com/autozimu/LanguageClient-neovim/commit/810aebe9a4824cf7c22b0208322cddd398d9ca3d
Heuristic snippet support is updated so that only neosnippet is equal to true, https://github.com/autozimu/LanguageClient-neovim/commit/657ad707d8732fc5a2139224cb00132880455904
For details, see https://github.com/autozimu/LanguageClient-neovim/issues/379 and https://github.com/autozimu/LanguageClient-neovim/issues/396
Neovim virtual text is supported. Of course with option to turn it off if you'd like https://github.com/autozimu/LanguageClient-neovim/blob/273e5dc44cf1f860e40999ee47ad9cb214ffd94c/doc/LanguageClient.txt#L343-L348
To customize the highlight group to use for virtual text, https://github.com/autozimu/LanguageClient-neovim/blob/273e5dc44cf1f860e40999ee47ad9cb214ffd94c/doc/LanguageClient.txt#L103
Hover content will be displayed in a floating window whenever possible (implemented in neovim 0.4.0). Thanks to @rhysd. Call hover twice to switch into the floating window.
If you want to disable this behaviour, https://github.com/autozimu/LanguageClient-neovim/blob/c33c45dd8384c0a0dfe8e99c558415b5c656d5c8/doc/LanguageClient.txt#L350-L358
For more details, see https://github.com/autozimu/LanguageClient-neovim/pull/767
First of all, I'm really impressed with how much more pleasure I have reading docs from floating window! Thank you @rhysd and @autozimu for it! Great job!
Also I found that new implementation of floating window doesn't work as expected if vim is configured to persist&load views for all files, like:
au BufWinLeave,BufLeave * silent! mkview
au BufWinEnter * silent! loadview
This can be fixed in many different ways, but I came up with this one for now:
au BufWinLeave,BufLeave * if @% != '__LanguageClient__' | silent! mkview
au BufWinEnter * if @% != '__LanguageClient__' | silent! loadview
Hopefully this will be useful for someone.
P.S.
Would be nice to configure '__LanguageClient__' buffer to not write views somehow, but I wasn't able to figure this out yet.
@saks Thank you for the point and sharing the solution. Perhaps checking buftype option might be more generic solution. buftype=nofile is set to buffer which does not represent a file buffer.
au BufWinLeave,BufLeave * if &buftype != 'nofile' | silent! mkview | endif
au BufWinEnter * if &buftype != 'nofile' | silent! loadview | endif
Not working :mksession on floating window may be a bug of Neovim but I'm not sure since I'm usually not using session.
Release 0.1.156 contains breaking changes regarding setting g:LanguageClient_useVirtualText. Valid options are updated from boolean value to enum. Checkout corresponding documentation if you're affected, https://github.com/autozimu/LanguageClient-neovim/blob/fb02afed15363c8879277b413b89e6ca51589e6a/doc/LanguageClient.txt#L343-L348
@zoj613 not sure what you mean. If what you are looking for is the plugin placing placeholders for the parameters of the function it suggested in autocompletion that can already be done (with the help of a snippet plugin). If you can describe this a little better and open an issue I think it would be a better place to discuss it.
@zoj613 not sure what you mean. If what you are looking for is the plugin placing placeholders for the parameters of the function it suggested in autocompletion that can already be done (with the help of a snippet plugin). If you can describe this a little better and open an issue I think it would be a better place to discuss it.
I meant something like getting a preview window displaying the autocompleted function's signature to help fill out arguments during editing.
Ok so you mean something like #196. If you want we can continue the discussion about that on that issue, but yeah, it's on our TODO list.