Separate list of TODOs

[lervag]

Cf. #1085: @kiryph propose to add a dedicated table of todos similar to the table of contents. The following features should be considered:

• [ ] :VimtexToT and <plug>(vimtex-tot) (perhaps also a default mapping?)
• [ ] Denite source
• [ ] Option to hide TODOs from ToC

---

Should not work on this until #1107 has been resolved.

[dbmrq]

As the one who suggested adding TODOs to the ToC, I want to add that I agree a dedicated TODO list would be great. It just seemed easier to use the ToC at the time.

It would also be nice if it were possible to add other custom words to be matched.

I have the following custom ToC matcher, for instance:

let g:VimtexImportant = {
      \ 're' : g:vimtex#re#not_bslash . '\%\c\s*IMPORTANT\s*:?\s*\zs.*',
      \ 'in_preamble' : 1,
      \}

function! g:VimtexImportant.get_entry(context) abort dict
  return {
        \ 'title'  : 'IMPORTANT: ' .
            \ matchstr(a:context.file, '\(\/.*\).*\/\zs\a.*\.\a\a\a') .
            \ ' - line ' . a:context.lnum,
        \ 'number' : '[!]',
        \ 'file'   : a:context.file,
        \ 'line'   : a:context.lnum,
        \ 'level'  : a:context.max_level,
        \ 'rank'   : a:context.lnum_total,
        \ }
endfunction

let g:vimtex_toc_custom_matchers = [g:VimtexImportant]

It would be nice to just be able to set a variable like:

let g:vimtex_todo_keywords = ["TODO", "FIXME", "IMPORTANT"]

And comments starting with those keywords would show each in their own section in the dedicated TODO list.

It's just a suggestion, though. I already love Vimtex the way it is. :)

[clason]

Pie-in-the-sky suggestion: todonotes package integration! (Should be easy to do myself with the g:vimtex_todo_keywords, though.)

[lervag]

TLDR: Would people get angry if the todos were no longer present in the ToC, if there was a feature that collected and sorted the todos in a more general and usable manner (as proposed here)?

---

As you might know, I want to keep the number of options low. I'm wondering, would it be an OK solution if I separated the todos from the ToC alltogether? I.e., I could add the previously described todo functionality which will open an index window for navigating to various todos, and I can add an option to allow custom keywords as suggested by @dbmrq.

@clason How would a todonotes integration work? That is, I already parse the \todo commands and add them to the ToC, and in my proposal I would move this to the table of todos. What else is missing?

---

Note also: As discussed in #1085, I will be combing the various table of X with the location list to allow a more Vim like workflow for those who are accustomed to it.

[clason]

Pretty much nothing is missing; I didn't realize vimtex already parsed \todo (probably because I usually define \clasontodo etc. with different colors to distinguish my notes from my coauthors' -- but that can be handled with the custom keyword).

For what it's worth, I also think a separate list of todos (<leader>lT?) would be nicer than a combined ToC/ToT.

[lervag]

Happy to hear it. I'll work on this when I get the time, but I'll first solve #1107.

[lervag]

I've started to work on this now. The first step has been to refactor the parsing code. It will be the same for all kinds of tables. I've realized that it should be sufficient to have one interface for this, instead of n, where n is the number of supported content tables.

So, my current idea is to merge labels.vim and toc.vim and to instead allow a more interactive mapping to decide which type of content to display.

[lervag]

I've just opened a PR that should solve this issue, at least after discussions and adaptations. Please continue discussions there.

[clason]

Sorry to bump this issue; I thought it the least likely to disturb many people. I (recently, not sure since when) have the problem that the separate ToX mapping no longer trigger. I've defined these as, e.g.,

nnoremap <silent> <Leader>ltl :call g:toc_label.open()<cr>

This used to open (if I'm reasonably quick with the last <l>) the joint ToC with only the labels layer shown. But now it always opens the full ToC with all layers shown (i.e., the <localleader>lt mapping is "greedy"). Has something changed in the implementation? How can I disable the built-in lt mapping from my .vimrc (nunmap doesn't seem to do the trick)?

[lervag]

Yes, this is probably due to #1254. I think those changes were appropriate, but I also think it will mess with your personal mapping here. I think you can solve this with e.g. the following mapping (place it in your personal ftplugin/tex.vim:

nmap <buffer><silent> <leader>ltt <plug>(vimtex-toc-open)

The idea/principle is that vimtex will not create the default map if the target is already mapped, so, if you add this map to your personal configuration, or perhaps in an autocmd in your vimrc, then it will prevent the default <leader>lt map from being defined.

[clason]

Does it have to be a file type plugin (as I wrote before, these really don't fit my workflow)?

Can the default mapping be disabled via a vimrc option? (I understand being reticent to increase the number of options without need...)

[lervag]

No, it does not have to be a filetype plugin. But if you put this in your vimrc file, then you should use an autocmd, something like this:

augroup vimrc
  autocmd!
  autocmd FileType tex nmap <buffer><silent> <localleader>ltt <plug>(vimtex-toc-open)
augroup END

The autocmd! line should be added only the first time you use the vimrc augroup (or whatever you want to call it). That is, if you already specify autocommands in your vimrc file, these should also be added to an autocommand group, and the first time you specify the group, you should ensure that you remove all existing autocmds (in case you reload your vimrc file).

Btw., note the difference between <localleader> and <leader>; if you want to adhere to the vimtex standard, you should use <localleader> here.

[clason]

OK, I'll try it out when I get back to a computer -- thanks!

[clason]

Yes, that works, thank you very much!

[lervag]

No problem, happy to help :)