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

Updates, screenshots & GIFs #35

Open
autozimu opened this Issue Mar 23, 2017 · 49 comments

Comments

7 participants
@autozimu
Owner

autozimu commented Mar 23, 2017

(For update announcements only, please refrain from off-topic comments.)

@autozimu

This comment has been minimized.

Owner

autozimu commented Mar 23, 2017

Rename

rename

@autozimu

This comment has been minimized.

Owner

autozimu commented Mar 23, 2017

Hover

hover

@autozimu

This comment has been minimized.

Owner

autozimu commented Mar 23, 2017

Goto Definition

definition

@autozimu

This comment has been minimized.

Owner

autozimu commented Mar 23, 2017

Symbols

symbols

@autozimu

This comment has been minimized.

Owner

autozimu commented Mar 23, 2017

Completion

completion

@autozimu

This comment has been minimized.

Owner

autozimu commented Mar 23, 2017

Diagnostics

diagnostics

@autozimu

This comment has been minimized.

Owner

autozimu commented Aug 22, 2017

g:LanguageClient_signColumnAlwaysOn was deprecated.

Use set signcolumn=yes instead.

@chrisduerr chrisduerr referenced this issue Aug 23, 2017

Closed

RustFMT #110

@autozimu

This comment has been minimized.

Owner

autozimu commented Aug 24, 2017

Formatting

formatting

@autozimu

This comment has been minimized.

Owner

autozimu commented Aug 30, 2017

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",
        },
    }
@autozimu

This comment has been minimized.

Owner

autozimu commented Sep 21, 2017

Code Action

tty

@autozimu

This comment has been minimized.

Owner

autozimu commented Oct 15, 2017

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"
@autozimu

This comment has been minimized.

Owner

autozimu commented Oct 25, 2017

vim support is added in #151.

@autozimu

This comment has been minimized.

Owner

autozimu commented Dec 10, 2017

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

  1. more performant and more robust
  2. better support for vim
  3. 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.

@jordwalke

This comment has been minimized.

jordwalke commented Dec 10, 2017

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).

@autozimu

This comment has been minimized.

Owner

autozimu commented Dec 10, 2017

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.

@jordwalke

This comment has been minimized.

jordwalke commented Dec 11, 2017

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)

@languitar

This comment has been minimized.

languitar commented Dec 11, 2017

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.

@jordwalke

This comment has been minimized.

jordwalke commented Dec 11, 2017

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?

@autozimu

This comment has been minimized.

Owner

autozimu commented Dec 11, 2017

Note added to build locally. 379d42e

@autozimu

This comment has been minimized.

Owner

autozimu commented Dec 11, 2017

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.

@jordwalke

This comment has been minimized.

jordwalke commented Dec 11, 2017

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.

@tbodt

This comment has been minimized.

Contributor

tbodt commented Dec 12, 2017

It's not possible to delete blobs from the repo once you've pushed them. They stay part of the git history forever.

@jordwalke

This comment has been minimized.

jordwalke commented Dec 12, 2017

@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?

@tbodt

This comment has been minimized.

Contributor

tbodt commented Dec 12, 2017

@jordwalke not if the commits are still reachable, which they would be if this was done the obvious way

@jordwalke

This comment has been minimized.

jordwalke commented Dec 12, 2017

@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.

@jordwalke

This comment has been minimized.

jordwalke commented Dec 12, 2017

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.

@jordwalke

This comment has been minimized.

jordwalke commented Dec 12, 2017

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.

@autozimu

This comment has been minimized.

Owner

autozimu commented Dec 12, 2017

I see. This is genius! Will try on this model. Thanks.

@hauleth

This comment has been minimized.

hauleth commented Dec 30, 2017

@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?

@jordwalke

This comment has been minimized.

jordwalke commented Dec 30, 2017

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.

@autozimu

This comment has been minimized.

Owner

autozimu commented Jan 5, 2018

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,

  1. In initial installation, it fetches all tags.
  2. In :PlugUpdate, it won't fetch new tags not in current branch.
@jordwalke

This comment has been minimized.

jordwalke commented Jan 6, 2018

Sad!

@autozimu

This comment has been minimized.

Owner

autozimu commented Jan 6, 2018

@jordwalke

This comment has been minimized.

jordwalke commented Jan 6, 2018

Does specifying a commit work reliably?

@autozimu

This comment has been minimized.

Owner

autozimu commented Jan 6, 2018

@autozimu

This comment has been minimized.

Owner

autozimu commented Jun 17, 2018

New configuration g:LanguageClient_loggingFile

2.14 g:LanguageClient_loggingFile *g:LanguageClient_loggingFile*
Log file location.
Default: null
Valid options: any valid path.

@autozimu

This comment has been minimized.

Owner

autozimu commented Jun 20, 2018

New configuration g:LanguageClient_serverStderr

2.14 g:LanguageClient_serverStderr *g:LanguageClient_serverStderr*
Path for language server stderr.
Default: None
Valid options: any valid path.

@autozimu

This comment has been minimized.

Owner

autozimu commented Jul 3, 2018

New configuration g:LanguageClient_diagnosticsSignsMax

2.3 g:LanguageClient_diagnosticsSignsMax *g:LanguageClient_diagnosticsSignsMax*
Control how many diagnostics signs are displayed.
Default: v:null (Show all signs)
Valid options: v:null | number

@timfeirg

This comment was marked as off-topic.

timfeirg commented Jul 10, 2018

How can I jump to definition in a new pane, for example a vsplit? is there an option to enable this behavior?

@autozimu

This comment has been minimized.

Owner

autozimu commented Aug 20, 2018

New function LanguageClient#explainErrorAtPoint to show detailed error under cursor.

*LanguageClient#explainErrorAtPoint*
Signature: LanguageClient#explainErrorAtPoint(...)
Show detailed error under cursor.

image

@jordwalke

This comment has been minimized.

jordwalke commented Aug 20, 2018

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

@autozimu

This comment has been minimized.

Owner

autozimu commented Aug 28, 2018

New function LanguageClient#debugInfo to print out debug info.

LanguageClient#debugInfo
Signature: LanguageClient#debugInfo(...)
Print out debug info.

@ccb23

This comment was marked as off-topic.

ccb23 commented Sep 17, 2018

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",
        },
    }

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.

Repository owner locked and limited conversation to collaborators Sep 17, 2018

Repository owner unlocked this conversation Sep 17, 2018

@autozimu

This comment has been minimized.

Owner

autozimu commented Nov 9, 2018

rustDocument/implementations was removed #655.

rustDocument/implementations was removed from rls back in July - at this commit. It now uses the standard textDocument/implementation.

@autozimu

This comment has been minimized.

Owner

autozimu commented Nov 13, 2018

Event LanguageClientBufReadPost was renamed to LanguageClientTextDocumentDidOpenPost to make it more accurate. @810aebe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment