Open pidgeon777 opened 2 years ago
Probably doable, but I'm not sure it's necessary now that we have treesitter support. We can get so much more and better information from the treesitter parsers than we could ever get from a tags file. Do you encounter any situations where you have a tags file available but don't have access to a treesitter parser?
Yes, two main reasons:
ctags
covers a huge amount of languages.ctags
it is possible to define custom pattern based tags for all files/languages, standard or not, which is extremely helpful under certain situations, thanks to the customizable ctags
engine based on regex.In vista.vim
it is possible to define options such as:
" Executive used when opening vista sidebar without specifying it.
" See all the avaliable executives via `:echo g:vista#executives`.
let g:vista_default_executive = 'ctags'
" Set the executive for some filetypes explicitly. Use the explicit executive
" instead of the default one for these filetypes when using `:Vista` without
" specifying the executive.
let g:vista_executive_for = {
\ 'cpp': 'vim_lsp',
\ 'php': 'vim_lsp',
\ }
" Declare the command including the executable and options used to generate ctags output
" for some certain filetypes.The file path will be appened to your custom command.
" For example:
let g:vista_ctags_cmd = {
\ 'haskell': 'hasktags -x -o - -c',
\ }
tagbar
, which is purely based on ctags
, is highly configurable:
https://github.com/preservim/tagbar/blob/master/doc/tagbar.txt
An alternate suggestion: Rather than adding tags support directly to Aerial, perhaps support for tags could be added to null-ls as a textDocument/documentSymbol
source. Then, tags should work with Aerial via null-ls with no changes to Aerial required. As a bonus, this should make tags work with any other plugin that utilizes the textDocument/documentSymbol
LSP method.
I asked about implementing this in null-ls here. Some boilerplate would be necessary to add support for the textDocument/documentSymbol
method to null-ls, but it's doable.
Here is an example of tags→completion support that's already in null-ls; I think a tags→symbols source could re-use some of that code.
@pidgeon777 Thanks for the detailed explanation! I think this is a fair ask.
@b0o definitely agree that it makes a lot of sense to add to null-ls. If a bunch of work is done to convert tags format to LSP symbols format, that's be place where it would be the most useful.
I don't have the bandwidth to start on this immediately, but I am interested in it. I've never really used tags much, but that may be changing as I've started a new job and one of the repos I'm working with doesn't have any other options for indexed navigation.
I think that other than LSP it would be great to integrate results from tag files, such as
Tagbar
orvista.vim
.