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

ale_hover_cursor is not respected after ALE is initialized #4832

Open
k4yt3x opened this issue Sep 17, 2024 · 0 comments
Open

ale_hover_cursor is not respected after ALE is initialized #4832

k4yt3x opened this issue Sep 17, 2024 · 0 comments
Labels

Comments

@k4yt3x
Copy link

k4yt3x commented Sep 17, 2024

Information

VIM version

NVIM v0.10.1
Build type: Release

Operating System: Arch Linux 6.10.10-arch1-1

What went wrong

TL;DR: g:ale_hover_cursor is only checked when ALE is initializing. Setting this variable afterwards does not change ALE's behavior. Setting g:ale_hover_cursor in Lazy's config callback per ALE's README example does not work.

I recently started trying noice.nvim and noticed that a window pops up when I move my cursor around:

image_2024-09-17_13-08-51

After looking around and disabling different plugins like coc.nvim and others, I narrowed the issue down to ALE. After searching the internet and asking GPT, I tried adding these into my Nvim config, but they didn't help:

  • vim.g.ale_echo_cursor = 0
  • vim.g.ale_hover_cursor = 0
  • vim.g.ale_cursor_detail = 0

So I turned on debug logging and started tracing the code to see where it came from. Here's the traced callstack:

  • cursor.vim : ale#cursor#Echom : 17
  • cursor.vim : ale#cursor#TruncatedEcho : 41
  • hover.vim : ale#hover#HandleLSPResponse : 250
  • hover.vim : s:OnReady : 284
  • hover.vim : ale#hover#Show : 335
  • hover.vim : ale#hover#ShowTruncatedMessageAtCursor : 363
  • events.vim : ale#events#Init : 218

Specifically, after the initialization register the hover callback here on line 218 of events.vim:

ale/autoload/ale/events.vim

Lines 217 to 219 in a7ef181

if g:ale_hover_cursor
autocmd CursorHold * if exists('*ale#lsp#Send') | call ale#hover#ShowTruncatedMessageAtCursor() | endif
endif

... the ale#hover#ShowTruncatedMessageAtCursor function does not check for the g:ale_hover_cursor anymore:

ale/autoload/ale/hover.vim

Lines 350 to 371 in a7ef181

function! ale#hover#ShowTruncatedMessageAtCursor() abort
let l:buffer = bufnr('')
let l:pos = getpos('.')[0:2]
if !getbufvar(l:buffer, 'ale_enabled', 1)
return
endif
if l:pos != s:last_pos
let s:last_pos = l:pos
let [l:info, l:loc] = ale#util#FindItemAtCursor(l:buffer)
if empty(l:loc)
call ale#hover#Show(
\ l:buffer,
\ l:pos[1],
\ l:pos[2],
\ {'truncated_echo': 1},
\)
endif
endif
endfunction

In other words, changing this variable after the callback is registered won't alter ALE's behavior. I am reporting this as a "bug" because this is not my expected behavior. In ALE's documentations, we can set variables in Lazy's config section:

ale/README.md

Lines 296 to 312 in a7ef181

#### [lazy.nvim](https://github.com/folke/lazy.nvim)
```lua
{
'dense-analysis/ale',
config = function()
-- Configuration goes here.
local g = vim.g
g.ale_ruby_rubocop_auto_correct_all = 1
g.ale_linters = {
ruby = {'rubocop', 'ruby'},
lua = {'lua_language_server'}
}
end
}
```

However, setting vim.g.ale_hover_cursor in the config callback function doesn't really work:

image

It has to be set before require('lazy').setup() is executed, so I think this is a bit counterintuitive. Perhaps it'll be better to add another check for the variable in ale#hover#ShowTruncatedMessageAtCursor or somewhere that makes it possible to change ale_hover_cursor on the fly without doing ALEToggle twice?

In the event this won't be fixed, for anyone that's having the same issue, just do vim.g.ale_hover_cursor = 0 before require('lazy').setup() and it should be fine.

Reproducing the bug

  1. Install folke/noice.nvim
  2. Install ALE
  3. Open a file with LSP support and move the cursor onto a symbol. Notice how an echom command pops up.

:ALEInfo

Expand
@k4yt3x k4yt3x added the bug label Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant