Технически я использую Tagbar в vim для просмотра тегов файла, но этот вопрос должен применяться в целом к буйным ctags, v5.8.Могу ли я добавить информацию об объеме в теги, сгенерированные с помощью `--regex- <LANG>` в буйных ctags?
Предположим, что у меня есть следующий файл питона, назовем его foo.py
:
class foo:
def bar(baz):
print(baz)
Бежим ctags
на нем: ctags foo.py
. Полученный tags
файл выглядит следующим образом:
!_ some ctags version/formatting stuff not worth pasting
bar foo.py /^ def bar(baz):$/;" m class:foo
foo foo.py /^class foo:$/;" c
бит Я заинтересован в последнее поле второй линии, class:foo
. Это область функции bar()
. Если я использую tagbar в vim, он соответствующим образом устанавливает функцию в классе.
Теперь предположим, что я добавляю поддержку нового языка в своем ~/.ctags
. На самом деле, я добавил поддержку для этого марионеточного файла:
class foo {
include bar
}
Предположим, я использую следующие ~/.ctags
аргументы. «Импорт» регулярное выражение некрасиво (эээ ... некрасиво для регулярных выражений), но он получает работу достаточно для этого примера:
--langdef=puppet
--langmap=puppet:.pp
--regex-puppet=/^class[ \t]*([:a-zA-Z0-9_\-]+)[ \t]*/\1/c,class,classes/
--regex-puppet=/^\ \ \ \ include[ \t]*([:a-zA-Z0-9_\-]+)/\1/i,include,includes/
Это порождает следующий тег в моем tags
файле:
bar foo.pp /^ include bar$/;" i
foo foo.pp /^class foo {$/;" c
Обратите внимание: ни одна строка не содержит обзорную информацию. Мой вопрос таков: есть ли в любом случае для меня построить аргумент --regex-puppet
или --regex-<LANG>
строк, чтобы собрать информацию о области тега? Чтобы, возможно, объявить, что теги, отвечающие критерию A, всегда будут областями-родителями тегов, удовлетворяющими критерию B?
man ctags
не предполагает четкого способа добавить произвольную информацию области действия, но я мог бы быть с видом другое решение (слегка надрезается для выразительности):
--regex-<LANG>=/regexp/replacement/[kind-spec/][flags]
Unless modified by flags, regexp is interpreted as a Posix extended regular expression. The replacement should expand for all matching lines to a non-empty string of
characters, or a warning message will be reported. An optional kind specifier for tags matching regexp may follow replacement, which will determine what kind of tag is
reported in the "kind" extension field (see TAG FILE FORMAT, below). The full form of kind-spec is in the form of a single letter, a comma, a name (without spaces), a
comma, a description, followed by a separator, which specify the short and long forms of the kind value and its textual description (displayed using --list-kinds). Either
the kind name and/or the description may be omitted. If kind-spec is omitted, it defaults to "r,regex". Finally, flags are one or more single-letter characters having the
following effect upon the interpretation of regexp:
b The pattern is interpreted as a Posix basic regular expression.
e The pattern is interpreted as a Posix extended regular expression (default).
i The regular expression is to be applied in a case-insensitive manner.