g:uctags_match_map

Default: See plugins/uctags/uctags_globals.vim
A dictionary containing $kinds that map to a pattern to be used for when using syn-match during creating (Or updating) Syn Files.

There is two formats that can be used:

1. {kind}: { 'start': {start-pattern}, 'end': {end-pattern} }
2. {lang}: [{kind}: { 'start': {start-pattern}, 'end': {end-pattern} }]

The former binds for $kind, barring $kind is not bound to the language of the source file; thus, the latter having precedence.

if !exists('g:uctags_match_map')
  let g:uctags_match_map = {}
endif

let g:uctags_match_map['c++'] =
      \ { 'member': { 'start': '/\%\(\.\|->\)\<\zs', 'end': '\>/' } }

let g:uctags_match_map['c#']  =
      \ { 'method': { 'start': '/\<', 'end': '\ze\s*\%\((\|<\)/' },
      \   'field' : { 'start': '/\<', 'end': '\>\(\s*(\)\@!/' } }

let g:uctags_match_map['go']  = { 'member': g:uctags_default_match }

" Lets refer to these as 'global patterns'
let g:uctags_match_map['member'] = { 'start': '/\<', 'end': '\ze\s*(/' }
let g:uctags_match_map['method'] = { 'start': '/\<', 'end': '\ze(/' }
let g:uctags_match_map['field']  = { 'start': '/\<', 'end': '\ze(/' }

Lets break this down, first taking a look at the last 3 lines:

1. The last 3 lines demonstrate how the last format is used, and define global patterns for the following $kinds:

   • "member"
   • "method"
   • "field"

   These patterns will be used for every $kind of all languages, except for languages there is already a key for, and that key has a key-value pair that has a key of one the three $kinds.

2. let g:uctags_match_map['c++'] demonstrates how the first format is used, and defines pattern for the $kind "member".

   In the first point, the $kind "member" was already defined, but the pattern used is different than that of what was defined for the $kind "member" when the language of the source file is C++.

   The global pattern for the $kind "member" may be suitable for most languages, but for some such as C++, and many others; using the global pattern wont accurately highlight a member. Therefore, using the global pattern for the syn-pattern section of a syn-match command when creating Syn Files, wont always be appropriate, which is why we define different patterns for languages that the global patterns wouldn't be appropriate for.

3. For let g:uctags_match_map['c#'], the principle is the same as the second point: The global patterns for the $kind "method" and "field" aren't appropriate to be used if the source file is of language C#.

   The reason why C# is shown here, is just so you can see that you can defined multiple $kinds for a particular language.

4. Lastly, let g:uctags_match_map['go'], similar to when the language of the source file was C++; the global pattern for the $kind "member" is not appropriate for when the source file is of the language go.

   For the language go, the default pattern―g:uctags_default_match―is appropriate, which is why we have assigned it to be used for the $kind "member" for the go language.

Languages used in g:uctags_match_map are required to be lowercase, and be specified identically to how Universal-Ctags would (Ignoring case: the languages need to be in lowercase). To see a list of languages supported by Universal-Ctags and how a language should be represented, run the following command in a terminal of your choosing:

ctags-universal --list-languages