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

Updates #35

Open
autozimu opened this issue Mar 23, 2017 · 59 comments
Open

Updates #35

autozimu opened this issue Mar 23, 2017 · 59 comments

Comments

@autozimu
Copy link
Owner

autozimu commented Mar 23, 2017

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

@autozimu
Copy link
Owner Author

autozimu commented Mar 23, 2017

Rename

rename

@autozimu
Copy link
Owner Author

Hover

hover

@autozimu
Copy link
Owner Author

Goto Definition

definition

@autozimu
Copy link
Owner Author

Symbols

symbols

@autozimu
Copy link
Owner Author

Completion

completion

@autozimu
Copy link
Owner Author

Diagnostics

diagnostics

@autozimu
Copy link
Owner Author

g:LanguageClient_signColumnAlwaysOn was deprecated.

Use set signcolumn=yes instead.

@chrisduerr chrisduerr mentioned this issue Aug 23, 2017
@autozimu
Copy link
Owner Author

Formatting

formatting

@autozimu
Copy link
Owner Author

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
Copy link
Owner Author

Code Action

tty

@autozimu
Copy link
Owner Author

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
Copy link
Owner Author

vim support is added in #151.

@autozimu
Copy link
Owner Author

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
Copy link

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
Copy link
Owner Author

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Owner Author

Note added to build locally. 379d42e

@autozimu
Copy link
Owner Author

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
Copy link

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
Copy link
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
Copy link

@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
Copy link
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

@autozimu
Copy link
Owner Author

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.

@autozimu
Copy link
Owner Author

New function LanguageClient#debugInfo to print out debug info.

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

@ccb23

This comment has been minimized.

Repository owner locked and limited conversation to collaborators Sep 17, 2018
Repository owner unlocked this conversation Sep 17, 2018
@autozimu
Copy link
Owner Author

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
Copy link
Owner Author

autozimu commented Nov 13, 2018

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

@autozimu
Copy link
Owner Author

Heuristic snippet support is updated so that only neosnippet is equal to true, 657ad70

For details, see #379 and #396

@autozimu
Copy link
Owner Author

autozimu commented Jan 30, 2019

Neovim virtual text is supported. Of course with option to turn it off if you'd like

2.22 g:LanguageClient_useVirtualText *g:LanguageClient_useVirtualText*
Specify whether to use virtual text to display diagnostics.
Default: 1 whenever virtual text is supported.
Valid Options: 1 | 0

To customize the highlight group to use for virtual text,

"virtualTexthl": "Error",

@autozimu autozimu changed the title Updates, screenshots & GIFs Updates Feb 9, 2019
@autozimu
Copy link
Owner Author

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,

2.26 g:LanguageClient_useFloatingHover *g:LanguageClient_useFloatingHover*
When the value is set to 1, |LanguageClient#textDocument_hover()| opens
documentation in a floating window instead of preview.
This variable is effective only when the floating window feature is
supported.
Default: 1 when a floating window is supported, otherwise 0
Valid Options: 1 | 0

For more details, see #767

@saks

This comment has been minimized.

@rhysd

This comment has been minimized.

@saks

This comment has been minimized.

Repository owner locked and limited conversation to collaborators Apr 2, 2019
Repository owner unlocked this conversation Apr 2, 2019
@autozimu
Copy link
Owner Author

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,

2.25 g:LanguageClient_useVirtualText *g:LanguageClient_useVirtualText*
Specify whether to use virtual text to display diagnostics.
Default: "All" whenever virtual text is supported.
Valid Options: "All" | "No" | "CodeLens" | "Diagnostics"

@zoj613

This comment has been minimized.

@martskins

This comment has been minimized.

@zoj613

This comment has been minimized.

@martskins

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants