mirror of
https://github.com/gryf/tagbar.git
synced 2025-12-17 11:30:28 +01:00
Some clarifications in the documentation
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
*tagbar.txt* Display tags of a file in their correct scope
|
||||
*tagbar.txt* Display tags of a file ordered by scope
|
||||
|
||||
Author: Jan Larres <jan@majutsushi.net>
|
||||
Licence: Vim licence, see |license|
|
||||
@@ -184,7 +184,7 @@ closed. By default the window is opened on the right side, set the option
|
||||
|:TagbarClose| will simply close the window if it is open.
|
||||
|
||||
It is probably a good idea to assign a key to these commands. For example, put
|
||||
this in your |vimrc|:
|
||||
this into your |vimrc|:
|
||||
>
|
||||
nnoremap <silent> <F9> :TagbarToggle<CR>
|
||||
<
|
||||
@@ -579,9 +579,23 @@ complicated cases.
|
||||
|
||||
Tagbar has a flexible mechanism for extending the existing file type (i.e.
|
||||
language) definitions. This can be used both to change the settings of the
|
||||
existing types and to add completely new types. A complete configuration
|
||||
consists of a type definition for Tagbar in your |vimrc| and optionally a
|
||||
language definition for ctags in case you want to add a new language.
|
||||
existing types and to add completely new types. For Tagbar to support a
|
||||
filetype two things are needed: a program that generates the tag information,
|
||||
usually Exuberant Ctags, and a Tagbar type definition in your |vimrc| that
|
||||
tells Tagbar how to interpret the generated tags.
|
||||
|
||||
There are two ways to generate the tag information for new filetypes: add a
|
||||
definition to Exuberant Ctags or create a specialized program for your
|
||||
language that generates ctags-compatible tag information (see
|
||||
|tags-file-format| for information about how a "tags" file is structured). The
|
||||
former allows simple regular expression-based parsing that is easy to get
|
||||
started with, but doesn't support scopes unless you instead want to write a
|
||||
C-based parser module for Exuberant Ctags. The regex approach is described in
|
||||
more detail below.
|
||||
Writing your own program is the approach used by for example jsctags and can
|
||||
be useful if your language can best be parsed by a program written in the
|
||||
language itself, or if you want to provide the program as part of a complete
|
||||
support package for the language.
|
||||
|
||||
Before writing your own extension have a look at the wiki
|
||||
(https://github.com/majutsushi/tagbar/wiki/Support-for-additional-filetypes)
|
||||
@@ -671,7 +685,8 @@ ctagsbin: The path to a filetype-specific ctags-compatible program like
|
||||
used automatically if found in your $PATH and does not have to be
|
||||
set in that case. If it is not in your path you have to set this
|
||||
key, the rest of the configuration should not be necessary (unless
|
||||
you want to change something, of course).
|
||||
you want to change something, of course). Note: if you use this
|
||||
then the "ctagstype" key is not needed.
|
||||
ctagsargs: The arguments to be passed to the filetype-specific ctags program
|
||||
{optional} (without the filename). Make sure you set an option that makes the
|
||||
program output its data on stdout. Not used for the normal ctags
|
||||
@@ -900,9 +915,9 @@ file.
|
||||
def bar(self):
|
||||
pass
|
||||
<
|
||||
I haven't found a clean way around this yet, but it shouldn't be much of a
|
||||
problem in practice anyway. Tags with the same name at any other level are
|
||||
no problem, though.
|
||||
I haven't found a proper way around this yet, but it shouldn't be much of
|
||||
a problem in practice anyway. Tags with the same name at any other level
|
||||
are no problem, though.
|
||||
|
||||
==============================================================================
|
||||
8. History *tagbar-history*
|
||||
|
||||
Reference in New Issue
Block a user