tags list is loading slow

[rrykim]

Hi,

It takes more than 5 minutes to fully load a tags file with about 16000 lines. (tags.zip)

files, grep_porject can handle more than that within few seconds.

Could you look into this issue?

[ibhagwan]

That's actually "by design" (read: bad design), the reason being is that before I had the builtin neovim previewer I had to provide line/column for the pattern so that the fzf previewer (bat/cat/etc) will be able to find the right offset inside the file, to do that fzf-lua runs rg for each tag to get the correct line/column and adds it to fzf.

It was a hack but since not many people use tags (LSP symbols are better IMO) and no one complained, I left it as is with the intention of fixing it one day as per the below:

Since the implementaiton of the builtin previewer (which is a neovim buffer) I can now feed the tag file as is into fzf and then search for the tag pattern inside the preview buffer.

I am now working on a major performance enhancement to make the files/grep providers icon/git indicator parsing run in an external process to make is as close as possible to running with { git_icons=false, file_icons=false } (try it if you haven't and see how fast it is), once I'm done with that I'll fix the tags for you.

[rrykim]

Cool! That makes total sense.

[yujinyuz]

@ibhagwan i have this in my config

require('fzf-lua').setup({
  files = {
    git_icons = false,
    file_icons = false,
  },
  tags = {
    git_icons = false,
    file_icons = false,
  },
})

The first part, the tags file is still loading. The second one is from fzf.vim.

Are you still refactoring the tags part?

I would want to use LSP symbols but I still need to open a file before an lsp server is loaded. Compared to fzf wherein I can load the tags file even without opening anything yet

[ibhagwan]

@yujinyuz, the tags fix wasn’t implemented yet, probably tomorrow or the day after and it will be as fast as fzf.vim.

[yujinyuz]

Thanks @ibhagwan

Looking forward to it as I am switching from Telescope to Snap to fzf-lua

[ibhagwan]

Decided to do this before I finish the other task, update to the latest commit: 46c9e2b

This commit also overrides the default previewer for tags and btags so it ignores winopts.previewer.default (can be overridden if you wish) and adds a new highlight under winopts.hl.search (default Search') which determines how to highlight the ctag matched pattern, see below

I just discoverd one outstanding issue, opening the match doesn't bring the cursor to the correct line, will fix that in a few minutes.

Try it out and lmk?

[ibhagwan]

e7c4970 - this makes sure to jump to the correct pattern when opening the buffer.

Lmk if this works well for you?

[ibhagwan]

I am switching from Telescope to Snap to fzf-lua

@yujinyuz, out of curiousity, why did you decide to switch?

[yujinyuz]

@ibhagwan I'll try that.

I'm switching because telescope has a bug with folds.

See: nvim-telescope/telescope.nvim#699

I switched to snap which was quite fast but I was occasionally having ENOENT problems

See: camspiers/snap#49

And I was about to just go back to fzf.vim but I found your plugin so I'll be using this for now and see if I have problems

[rrykim]

It takes about 2-3 seconds to load the tags file, while it is instantaneous using fzf.vim.
Further improvement would be welcome.

Also the cursor rarely jump to the incorrect line. The behavior is quite unpredictable now.

[ibhagwan]

It takes about 2-3 seconds to load the tags file, while it is instantaneous using fzf.vim. Further improvement would be welcome.

There's def room for improvement in the parsing code, I'll take a look after I'm done with the bigger perf improvements I'm working on, 2-3 seconds sounds managable.

Also the cursor rarely jump to the incorrect line. The behavior is quite unpredictable now.

The cursor jump uses search(<pattern>) to go to the correct line, it also uses the same search to find the correct line in the preview, can you tell if the line appears correctly in the preview or is it wrong there as well?

[rrykim]

The cursor jump uses search(<pattern>) to go to the correct line, it also uses the same search to find the correct line in the preview, can you tell if the line appears correctly in the preview or is it wrong there as well?

The highlighted line in the preview window is always correct.