Linters get confused

[adelin-b]

Here is a small issue I have : When easymotion is used the linter get mad. Any tips on where to hook to know if linter should lint or if someone implemented that ?

[dlants]

I think this is an issue with how the motion targets get shown. It seems like it changes the actual text of the buffer, and many linters with live linting will try to send the contents of the buffer for linting. (I ran into this on https://github.com/neoclide/coc-tsserver and it seems to be a problem for Language Server Protocol plugins in general).

Seems like neovim is considering some things that may help:

https://github.com/neovim/neovim/issues/8068 https://github.com/neovim/neovim/issues/1767

[rocinante42]

I got just the same problem using (https://github.com/neoclide/coc-tsserver) did you guys get a way around this issue?

[dseeni]

same issue here.. wondering if there is a workaround to linter triggering

[vieko]

Same issue as well.

[zer09]

I would like to use easymotion-bd-w but coc got mad, so for now gonna only use easymotion-overwin-f2

[vieko]

I resolved to using vim-sneak for now, hoping one day this is addressed.

[dlants]

@vieko does label-mode in vim-sneak not have this issue? I tried looking through that repo and it seems that they use highlighting somehow to display labels though I'm not familiar enough with vim-script to tell how they actually do it...

[vieko]

label-mode works just fine for vim-sneak, good call! There's bound to be a hint / trail to follow here.

[iago-lito]

Hey, same problem here with coc-rust-analyzer. So I cross-post the issues for reference.

I thought easymotion hints were displayed using virtual text, and not actual changes to the buffer. Can virtual text be used to display easymotion hints? Or can it only be used where there is no actual text? I suspect no linter would be confused if hints were displayed using virtual text instead, but then maybe there would be conflicts to solve between the actual linter messages and easymotion hints?

[kswope]

There's an issue and workaround here, I'm trying it out now

https://github.com/neoclide/coc.nvim/issues/110

[numToStr]

I love easymotion and coc both. And this is the only issue that is making me stick to vscode. Hope easymotion provides a workaround to fix this issue

[kujbika]

Im facing the same issue.

[sekirocc]

I use this work around, posted here maybe someone else need it.

in ~/.config/nvim/init.vim

function! DoingEasyMotion()
    let g:is_doing_easymotion = 1
    let cancelled = EasyMotion#WB(0,2)
    let g:is_doing_easymotion = 0
endfunction
nmap f :call DoingEasyMotion()<CR>

the idea is setting a flag before easymotion function. then at somewhere else, use the flag to determine linter behavior. I use nvim-lua/diagnostic-nvim to do the linter thing (lsp diagnostic), so

lua << EOF
  local nvim_lsp = require'nvim_lsp'
  local completion = require'completion'
  local diagnostic = require'diagnostic'

  local orig = diagnostic.publish_diagnostics
  diagnostic.publish_diagnostics = function(bufnr, diagnostics)
    local status, result = pcall(vim.api.nvim_get_var, "is_doing_easymotion")
    if status == true or result == 1 then
      return
    end
    orig(bufnr, diagnostics)
  end

  local on_attach = function(_, bufnr)
    completion.on_attach()
    diagnostic.on_attach()
  end

  nvim_lsp.rust_analyzer.setup({on_attach=on_attach})
  nvim_lsp.gopls.setup({on_attach=on_attach})
EOF

[n-p-e]

Adding an User autocmd should make this a lot easier. Please take a look at my PR.

[ecesar88]

Any insight on this?

[kswope]

I saw something here

https://github.com/easymotion/vim-easymotion/pull/440#issuecomment-727844125

[ivanterrible]

The autocmd change mentioned in #440 is an okay temporary fix with one major issue. When you listen to that event it triggers all folds to close making easymotion unusable on any buffer with folds unless you have a very high foldlevel.

[timsu92]

It seems that all of you meant coc and not other linters. I'm marking this issue to be solved on my PR.

[quantumfate]

Switch to hop as shown here you can also integrate it in vscode without any extra configuration: https://github.com/phaazon/hop.nvim/issues/349

Since this etension doesn't write to the buffer it also works native in vscode

[yogeshlonkar]

There seems to be repetitive EasyMotionPromptBegin EasyMotionPromptEnd user events if motion requires more than 1 keypress to move cursor. Because of this autocmd doesn't work correctly with native nvim lsp.

I have this below workaround

vim.api.nvim_create_autocmd("User", {pattern = {"EasyMotionPromptBegin"}, callback = function() vim.diagnostic.disable() end})
function check_easymotion()
  local timer = vim.loop.new_timer()
  timer:start(500, 0, vim.schedule_wrap(function()
    -- vim.notify("check_easymotion")
    if vim.fn["EasyMotion#is_active"]() == 0 then
      vim.diagnostic.enable()
      vim.g.waiting_for_easy_motion = false
    else
      check_easymotion()
    end
  end))
end
vim.api.nvim_create_autocmd("User", {
  pattern = "EasyMotionPromptEnd",
  callback = function()
    if vim.g.waiting_for_easy_motion then return end
    vim.g.waiting_for_easy_motion = true
    check_easymotion()
  end
})

but it required cursor to move at least once after EasyMotion to enable the diagnostics.

I'll see if I can create PR to fix this behaviour