completion is missing equation labels when using autonum

[ces42]

This is a rather low-priority issue.
Is your feature request related to a problem? Please describe it.
When using the autonum package¹ equations that are \labeled but not \referenced don't appear in the aux file. Hence they don't appear in vimtex's completion.

Describe the solution you'd like
Maybe it would be possible to just search the current file for \labels and add those to the completion function?. This would also fix \labels not appearing in completion if the document has not been compiled since they were added (which happens frequently because most of time you add a \label you will \reference it right away.)

Footnotes

1. The main feature of this package is that \labeled equations in the source that don't \referenced don't get labeled in the pdf ↩

[lervag]

Interesting request. I have not heard of autonum before.

Describe the solution you'd like Maybe it would be possible to just search the current file for \labels and add those to the completion function?. This would also fix \labels not appearing in completion if the document has not been compiled since they were added

Well, it's a relatively big and complex change, because we would need to merge the results. To be honest, I'm not very motivated to work on this, as I don't see myself needing or using this feature. But I won't mind considering a PR for it.

(which happens frequently because most of time you add a \label you will \reference it right away.)

For me, this never really happened frequently. Perhaps because I save more often than you?

[shivangp76]

I don't use the autonum package, but I've also wanted \labels to be used for completion without compiling the document first. I've been using the following code as a workaround. Instead of adding it to the completion function, it creates a new keybinding. Hope this somewhat helps with your issue. Note that the fzf package used here is ibhagwan/fzf-lua.

vim.cmd([[
function! OrderLabels(l1, l2)
  return a:l1[1] == a:l2[1] ? 0 : a:l1[1] > a:l2[1] ? 1 : -1
endfunction
" Sorts labels by proximity to the cursor position, since recently created labels are likely to be references. Also removes VimTeX's dependence on LaTeX rendering to get labels.
function! GetLabels()
  let l:result = []
  let l:regex_pattern = '\\label{\([^}]*\)}'
  let l:cursor_line = line('.')
  for line_number in range(1, line('$'))
    let l:line = getline(l:line_number)
    let l:distance = abs(l:cursor_line - l:line_number)
    call substitute(l:line, l:regex_pattern, '\=add(l:result, [submatch(1), distance])', 'g')
  endfor
  return sort(l:result, "OrderLabels")
endfunction
function! PasteLabel(label)
  execute "normal! a" . a:label
  call feedkeys('a')
endfunction
function! FzfLabels()
  call fzf#run({
      \'source': map(GetLabels(), 'v:val[0]'),
      \'sink': function('PasteLabel'),
      \'window': {'width': 0.9, 'height': 0.6},
      \})
endfunction
]])
vim.keymap.set('i', '<C-f>', '<Esc>:call FzfLabels()<CR>', { silent = true, noremap = true, buffer = true })

[lervag]

Ok, let's say I were to consider implementing label completion based on manual parsing of the LaTeX file. How should it behave with respect to the current completion parser? For instance, this might work:

1. If the document is not compiled, then we fallback to a manual parsing that will only show the available labels without any additional metadata.
2. If the document is compiled, then use the current parser that brings more metadata.
3. Same as 2, but combine the results to include labels from the manual parsers (1) if they are not present in the "fancy" parser.

Thoughts?

[shivangp76]

That sounds good to me, assuming "compiled" means "compiled with the latest changes." In other words, if we can ensure manual parsing will add no benefit, then we will skip it and just do fancy parsing. Otherwise, do manual and fancy parsing.

[lervag]

I'm pushing an update for this now. Sorry for being so slow!

With the latest update, we will add completion candidates as I suggested above: fancy + manual, but with duplicates removed.

[lervag]

For anyone curious, I did a writeup of my experience solving this issue with Claude Code: https://lervag.github.io/posts/claude-code/.