Updates
autozimu opened this issue · 59 comments
(For update announcements only, please refrain from off-topic comments.)
Rename
Hover
Goto Definition
Symbols
Completion
Diagnostics
g:LanguageClient_signColumnAlwaysOn was deprecated.
Use set signcolumn=yes instead.
Formatting
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",
},
}
Code Action
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?
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.
I see. This is genius! Will try on this model. Thanks.
@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.
Sad!
Does specifying a commit work reliably?
New configuration g:LanguageClient_loggingFile
LanguageClient-neovim/doc/LanguageClient.txt
Lines 184 to 189 in 9a316ef
New configuration g:LanguageClient_serverStderr
LanguageClient-neovim/doc/LanguageClient.txt
Lines 198 to 203 in e5e44f2
New configuration g:LanguageClient_diagnosticsSignsMax
LanguageClient-neovim/doc/LanguageClient.txt
Lines 108 to 113 in bb733ef
New function LanguageClient#explainErrorAtPoint to show detailed error under cursor.
LanguageClient-neovim/doc/LanguageClient.txt
Lines 553 to 556 in 5e96854
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.
LanguageClient-neovim/doc/LanguageClient.txt
Lines 567 to 570 in 542203b
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. @810aebe
Neovim virtual text is supported. Of course with option to turn it off if you'd like
LanguageClient-neovim/doc/LanguageClient.txt
Lines 343 to 348 in 273e5dc
To customize the highlight group to use for virtual text,
LanguageClient-neovim/doc/LanguageClient.txt
Line 103 in 273e5dc
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,
LanguageClient-neovim/doc/LanguageClient.txt
Lines 350 to 358 in c33c45d
For more details, see #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! loadviewThis 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! loadviewHopefully 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 | endifNot 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,
LanguageClient-neovim/doc/LanguageClient.txt
Lines 343 to 348 in fb02afe
any plans to support function signature display upon autocompletion?
@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.
