bug: target for listing lsp_references is offset after viewing document_diagnostics

[MaazSiddiqi]

Did you check docs and existing issues?

• [X] I have read all the trouble.nvim docs
• [X] I have searched the existing issues of trouble.nvim
• [X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.10.0-dev-1582+gc194acbfc-Homebrew

Operating system/version

MacOS 13.3.1

Describe the bug

When trying to view references, sometimes the target for the references is a few lines above the currently highlighted word.

In the snippet below, trying to view references for STEPS actually ends up showing diagnostics for profileBioFactory.

I found this seems to get fixed once I use nvim's native lsp alternatives for these functions, but once I use trouble diagnostics, it seems to get offset again.

import ProfileBio from './profileBio/ProfileBio';
import VerifyCoach from './verifyCoach/VerifyCoach';

import profileBioFactory from './profileBio/profileBioFactory';
import { signUp } from './useAuth';
import { calculateAgeFromBirthdate } from '../../utils/utils';
import { isAuth } from '../../auth/auth';
import { triggerEvent } from '../../hooks/useAnalytics';
import { TOTAL_WEEKLY_TIME_INDEXES } from '../../utils/availabilityUtils';

import styles from './SignUp.module.scss';

SignUp.propTypes = {
  coach: PropTypes.bool,
};

export default function SignUp({ coach = false }) {
  const STEPS = useMemo(
    () =>
      coach
        ? {
            VERIFYCOACH: 0,
            INFO: 1,
            // ORGANIZATION: 2,
            EXPERIENCES: 2,
            INTERESTS: 3,
            // BIOS: 5,
            AVAILABILITY: 4,
            TERMS: 5,
            VERIFICATION: 6,
            CONTINUE: 7,
          }
        : {
            INFO: 0,

Steps To Reproduce

1. View Trouble document diagnostics
2. Try to view some symbol's references

Expected Behavior

Should show references of the symbol under cursor.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  "folke/trouble.nvim",
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
-- new to this stuff, not sure how to use this...
-- just try open any file and view diagnostics then view references, it sometimes is offset.

[filipgodlewski]

I encountered the same issue today, and noticed one thing (although I have no idea if it is a coincidence or not): It occurs only if the searched item is BELOW the middle of the viewport. Let's say that my window can hold 50 LOC (not counting status line), then until line 25 everything will work just fine. After line 26 everything will be set off, and if I try to search for items that are at the very bottom of the window, I might get "index out of range" error:

Also, in my case, viewing document or any diagnostics was not needed to reproduce the issue.

[schemar]

I have the same issue and did some research. It's kinda hard to do, because it only happens sometimes, not all the time. It happens often enough to make Trouble more or less unusable in this regard, though.

The offset can be anywhere from 1 to dozens of lines.

In short: It appears that when I have multiple windows open, sometimes make_position_param returns the wrong line. vim.api.nvim_win_get_cursor(win) actually returns the wrong line for the cursor there.

Instead, when I call nvim_win_get_cursor() myself from within the buffer, the line number is correct.

Some more details:

1. When I use vim.lsp.buf.references instead of Trouble's lsp_references, I get the correct result.
2. When I use trouble, sometimes the line number is off.
   • I printed the row and column from ./lua/touble/util.lua::make_position_param(). There, the column is correct, but the row (line) is off. It looks like the result of vim.api.nvim_win_get_cursor(win) is off at that point.
   • It uses the correct win ID.
   • When I call vim.api.nvim_win_get_cursor(win) directly from the buffer, the line number is not offset. Only from within make_position_param().

Other Info that might be more confusing than helpful:

1. So far, I only noticed it when I had at least two windows open.
   • Sometimes (coincidence?) the line number was of the cursor in the other window.
2. It appears the offset is (almost?) always negative. At least very often.
   • E.g. cursor on line 55, Trouble thinks the cursor is on line 43.
   • Sometimes, the offset increases with subsequent invocations.
3. :e doesn't help.
4. For me, it's not related to being "high" or "low" in the window with the cursor.

Hope this helps anyone 😅 Would love to use trouble for references! 💚

EDIT: For me it's not relevant whether I viewed diagnostics before. But I think it never happens on the very first invocation generally.

EDIT2: Also, the cursor actually moves. After the operation, the cursor will be at the new position. It appears Trouble somehow moves the cursor even if it errors?

[schemar]

In summary: The line number changes somewhere in between the beginning of View.create() and View:on_win_enter() (when View.create calls below new before the call to View::new()).

---

One more observation:

At the beginning of function View:on_enter() (directly after self.parent = self.parent or vim.fn.win_getid(vim.fn.winnr("#"))):

1. The line number is already wrong.
   • Using vim.api.nvim_win_get_cursor(self.parent)
2. The line highlighting is still on the original, correct line.
   • Only does the cursor update after the Trouble window opened.

EDIT: It's already wrong at View.setup using:

  vim.api.nvim_win_get_cursor(vim.fn.win_getid(vim.fn.winnr("#")))))

EDIT2: Same for View:on_win_enter(). Already wrong there.

EDIT3: It's still correct at the beginning of Trouble.open(...) (and just before view = View.create(opts)).

[schemar]

@MaazSiddiqi / @filipgodlewski since this issue isn’t very popular, maybe it’s due to another plugin the three of us use?

Should we compare our list of plugins?

This is my NeoVim config: https://github.com/schemar/dotfiles/tree/main/configs/neovim

[folke]

do you have splitkeep set to topline or screen? Are you using any animation plugins?

[MaazSiddiqi]

do you have splitkeep set to topline or screen? Are you using any animation plugins?

not using any animation plugins, and splitkeep is set to screen.

@MaazSiddiqi / @filipgodlewski since this issue isn’t very popular, maybe it’s due to another plugin the three of us use?

Should we compare our list of plugins?

This is my NeoVim config: https://github.com/schemar/dotfiles/tree/main/configs/neovim

sure! my config is available here: https://github.com/MaazSiddiqi/.dotfiles/tree/main/nvim

[schemar]

do you have splitkeep set to topline or screen?

splitkeep=screen

Are you using any animation plugins?

Yes, I use neoscroll.nvim. However, disabling neoscroll doesn't help. The issue is still easily reproducible.

[filipgodlewski]

@folke I confirm, I have it set to screen. No animation plugins, but I have dressing.nvim installed.

[folke]

Does the issue disappear when setting splitkeep=cursor?

[folke]

See also https://github.com/neovim/neovim/issues/23888

[schemar]

Does the issue disappear when setting splitkeep=cursor?

I think so! I cannot guarantee it, of course, but I wasn't able to easily reproduce it anymore.

[folke]

ok, then it's probably caused by the issue I linked to. I can probably fix it on the trouble side, but it's tricky and other plugins can nullify the fix.

[schemar]

Thanks! For me, I'll just use splitkeep=cursor, no worries. And thanks for all your hard work and contributions 💚

[luukvbaal]

https://github.com/vim/vim/pull/12509 will likely fix this and the linked neovim issue. I will port the patch as soon as it is merged (Bram has not been very responsive the last few days😅).

[folke]

@luukvbaal that's great! fyi: this is not how I first discovered that issue :)

I've had it with an early version of edgy.nvim, but I was able to work around it eventually.

[andenkondor]

Are there any news on this? I have neovim version 0.9.5 and the issue still persists. :(

[folke]

Development on the main branch is EOL.

Trouble has been rewritten and will be merged in main soon.

This issue/feature either no longer exists or has been implemented on dev.

For more info, see https://github.com/folke/trouble.nvim/tree/dev