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

Plugin should not override ALE settings unless requested #569

Closed
macthecadillac opened this issue Aug 15, 2018 · 5 comments
Closed

Plugin should not override ALE settings unless requested #569

macthecadillac opened this issue Aug 15, 2018 · 5 comments

Comments

@macthecadillac
Copy link

macthecadillac commented Aug 15, 2018

  • Did you upgrade to latest plugin version? Yes
  • Did you upgrade to/compile latest binary? Yes
  • (Neovim users only) Did you check output of :checkhealth LanguageClient? Yes
  • Did you check troubleshooting? Yes

Describe the bug

I have my own very specific settings for how ALE displays symbols in the sign column but once I enable LanguageClient, it is partially overridden by your defaults. This plugin should have an option to disable such behavior.

Environment

  • neovim/vim version (nvim --version or vim --version):
NVIM v0.2.2
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-VavapE/neovim-0.2.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DDISABLE_LOG -Wdate-time -D_FORTIFY_SOURCE=2 -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/build/neovim-VavapE/neovim-0.2.2/build/config -I/build/neovim-VavapE/neovim-0.2.2/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/build/neovim-VavapE/neovim-0.2.2/build/src/nvim/auto -I/build/neovim-VavapE/neovim-0.2.2/build/include
Compiled by pkg-vim-maintainers@lists.alioth.debian.org

Features: +acl +iconv +jemalloc +tui 
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info
  • This plugin version (git rev-parse --short HEAD): 605c07e
  • This plugin's binary version (bin/languageclient --version): 0.1.110
  • Minimal vimrc content (A minimal vimrc is the smallest vimrc that could
    reproduce the issue. Refer to an example [here][min-vimrc.vim]):
call plug#begin('~/.config/nvim/plugged')
Plug 'w0rp/ale'
" Language server
Plug 'autozimu/LanguageClient-neovim', {
    \ 'branch': 'next',
    \ 'do': 'bash install.sh',
    \ }
call plug#end()

" Ale configuration
let g:ale_linters = {
  \   'rust': ['rls'],
  \}
let g:ale_set_highlights = 0
let g:ale_sign_error = 'x'
let g:ale_sign_warning = 'w'
let g:ale_lint_on_enter = 0
" rust specific options for ALE
let g:ale_rust_rls_executable = $HOME . '/.cargo/bin/rls'
let g:ale_rust_rls_toolchain = 'nightly'


" language server configuration
set hidden

let g:LanguageClient_serverCommands = {
    \ 'rust': ['~/.cargo/bin/rustup', 'run', 'stable', 'rls'],
    \ }

let g:LanguageClient_diagnosticsSignsMax = 0

To Reproduce

Steps to reproduce the behavior:

  1. Create a new cargo project
  2. Make a change so the linter shows an error
  3. Now disable LanguageClient from init.vim and open the file with the same error produced above
  4. Notice how the sign column is formatted differently

Current behavior

With LanguageClient enabled, ALE settings for the sign column is partially overridden.

Expected behavior

I expect that my ALE settings to be left untouched unless I specifically asked for it.

Screenshots

With LanguageClient disabled:
image

With LanguageClient enabled:
image

@macthecadillac macthecadillac changed the title Plugin should not overwrite ALE settings unless asked to Plugin should not overwrite ALE settings unless requested Aug 15, 2018
@macthecadillac macthecadillac changed the title Plugin should not overwrite ALE settings unless requested Plugin should not override ALE settings unless requested Aug 15, 2018
@autozimu
Copy link
Owner

This plugin never override ALE settings as far as I remember.

It defines its own sign types at

"sign define LanguageClient{} text={} texthl={}",

With definitions from

2.2 g:LanguageClient_diagnosticsDisplay *g:LanguageClient_diagnosticsDisplay*
Control how diagnostics messages are displayed.
Default: >
{
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",
},
}

Since you're disable sign drawing from this plugin, there shouldn't be any sign instances of this defined type shown anyway.

@smhc
Copy link

smhc commented Sep 6, 2018

You should be able to work around this with:

let g:LanguageClient_diagnosticsEnable=0

assuming you want to use ALE for linting instead.

@lukas-reineke
Copy link

This depends on the color scheme that is used.
If ALEErrorSign / ALEWarningSign / ALEInfoSign is set in the color scheme everything works fine, but if its not, this plugin clears the vaules.

:hi ALEErrorSign
ALEErrorSign   xxx cleared

Without this plugin it links to Error

:hi ALEErrorSign
ALEErrorSign   xxx links to Error

One solution is to just define the highlight groups
the other is to map LanguageClient_diagnosticsDisplay to other highlight groups

let g:LanguageClient_diagnosticsDisplay = {
\   1: { 'signTexthl': 'Error' },
\   2: { 'signTexthl': 'Todo' },
\   3: { 'signTexthl': 'Todo' },
\   4: { 'signTexthl': 'Todo' },
\}

@gbrlsnchs
Copy link

gbrlsnchs commented Apr 17, 2019

Is it possible to output LanguageClient-neovim errors through ALE?

Edit: I think it's not, so I opened #800 to track that. That should fix this issue too, as diagnostics would be unified.

@martskins
Copy link
Collaborator

As of #1144 LCN does no longer use ale's highlight groups, it instead defines it's own groups and uses that as a default, so this shouldn't be a problem anymore. If the problem persists thought, feel free to re-open.

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

No branches or pull requests

6 participants