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

Keep Trouble window quickfix list up to date as the document is edited #201

Closed
Hubro opened this issue Aug 8, 2022 · 9 comments · Fixed by #445
Closed

Keep Trouble window quickfix list up to date as the document is edited #201

Hubro opened this issue Aug 8, 2022 · 9 comments · Fixed by #445
Labels

Comments

@Hubro
Copy link

Hubro commented Aug 8, 2022

Currently, using :Trouble quickfix with gives a worse developer experience than using the built-in quickfix window plus :cnext/:cprevious.

The quickfix :cnext/:cprevious commands will jump to the correct line even if you've added/deleted lines higher up in the document. However, Trouble with require("trouble").next/previous(...) will jump to the exact line number from the quickfix list.

Any time I fix a linter warning, jumping to the next linter warning will take me to an unrelated line, which is a massive pain. After a few fixes, the jump location may not even be anywhere near the location of the linter warning, making the Trouble quickfix list useless.

Should the locations in the Trouble quickfix window be kept up-to-date as lines are added/deleted from the document? This would make it much, much easier to work with. Are there any drawbacks to doing this?


The logic sounds pretty trivial, and it would have to run any time a line is added or deleted:

  • Any time a line is added, any quickfix list item with a higher line number than the added line should have its row number incremented by one
  • Any time a line is deleted, any quickfix list item with a higher line number than the deleted line should have its row number decremented by one

I'm not very familiar with writing plugins for Vim/NVim, but I assume there are autocommands that trigger on document edits and APIs for figuring out which lines were added/removed.

@Hubro
Copy link
Author

Hubro commented Dec 1, 2022

Or, come to think of it, perhaps pressing <Enter> on a line in Trouble could just execute the same action that would be executed in the built-in quickfix list? That way, whatever logic Vim is doing to keep the line number up to date would be reused.

@folke folke added the fixed v3 label Mar 29, 2024
@folke
Copy link
Owner

folke commented Mar 29, 2024

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

@folke folke closed this as completed Mar 29, 2024
@folke folke reopened this May 30, 2024
@folke
Copy link
Owner

folke commented May 30, 2024

Allright, seems I didn't ready this fully.

I'll see if this can be added.

@xzbdmw
Copy link

xzbdmw commented May 30, 2024

Ah, it is indeed refreshed when I call require("trouble").next({ skip_groups = true, jump = true }), but getqflist will return linenumber that higher than actual line count if I delete some lines, cause trouble to throw errors

@folke
Copy link
Owner

folke commented May 30, 2024

It actually already works. You can do r in the trouble buffer to refresh.
Almost finished adding the correct refresh events to trouble.

@folke folke closed this as completed in c1d9294 May 30, 2024
@folke
Copy link
Owner

folke commented May 30, 2024

Fixed

@folke
Copy link
Owner

folke commented May 30, 2024

It only updates on TextChanged. If you also want it to update during insert, then you can add TextChangedI to your config.

@xzbdmw
Copy link

xzbdmw commented May 30, 2024

@folke If you delete lines between qflist results, trouble will throw errors, a simple gif showing that

iShot_2024-05-30_22.52.26.mp4

@folke
Copy link
Owner

folke commented May 30, 2024

@xzbdmw should be fixed now. I also fixed the event. It should only listen on changes on the main buffer, but it was listening on all buffer changes, inlcuding those of the trouble windows.

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

Successfully merging a pull request may close this issue.

3 participants