Open ssfrr opened 9 years ago
Having similar troubles with ctags.
The issue is that symbols-view inadvertently expects there to be patterns included in your generated ctags
. This is the default behavior for running ctags
(you can also explictly set it with the -F
, or --excmd=pattern
options). It looks like you are running ctags
with the number option (-n
or --excmd=number
), e.g ctags -R -n
.
A tag file with patterns instead of numbers looks something like this
DECA_PAN_ID src/DW1000.c /^#define DECA_PAN_ID /;" d file:
The code that expects this is here. When no actual pattern is present in the ctags file, node-ctags
interprets the number (e.g. 73;"
) as the pattern and is never able to match it a full line of text in the symbol's file.
This package should expect and accept both. The shortest path to this would be to check if tag.pattern
and tag.lineNumber
represent the same number, and if so create a Point based on line number instead of pattern. e.g.
getTagLine: (tag) ->
# Remove leading /^ and trailing $/
pattern = tag.pattern?.replace(/(^^\/\^)|(\$\/$)/g, '').trim()
# `ctags -excmd=number`, giving line numbers instead of patterns to locate
# symbols. The line number is being interpreted as a pattern by node-ctags
return new Point(tag.lineNumber - 1, 0) if tag.lineNumber is parseInt(pattern)
return unless pattern
file = path.join(tag.directory, tag.file)
return unless fs.isFileSync(file)
for line, index in fs.readFileSync(file, 'utf8').split('\n')
return new Point(index, 0) if pattern is line.trim()
I'm having the same issue with #define
in C. When clicking Go To Declaration
on the usage of the define nothing happens. Here's what ctags
generated. It's using patterns.
MY_VAR include/my_file.h /^#define MY_VAR /;" d
I am generating the tags file using ctags -R --excmd=pattern .
I have the following entry in my ctags file
but if I put my cursor over a usage of
DECA_PAN_ID
and run go-to-declaration nothing happens.This is with symbols-view 0.99.0