Make each convenience library depend on the ones it requires, which is
pretty straightforward for us as they each only depend on a single
other one, avoiding any worry about double linking of static objects.
At the moment tag types are changed in ctags to match the types Geany
uses internally. This introduces differences between the parsers used
in ctags and the ones used in Geany.
Instead, perform the "ctags tag type"->"geany tag type" mapping explicitly
in TM and leave the tag types in individual parsers identical to ctags.
For parsers which are present in ctags (and which don't seem to be
completely different from the parsers used in Geany) revert the tag type
change in the parsers so the parser tag definitions match universal-ctags.
This patch doesn't do anything with the tag types of parsers not present
in universal-ctags and leaves them as they are.
Parsers which previously had a mapping to an non-existent Geany type have
now the mapping explicitly set to tm_tag_undef_t. Since the mapping is now
made through the one-letter type, some of the parsers had to be adjusted
because they used single letter for multiple tag types (probably by
mistake).
Because the whole mapping process might be a bit fragile and error-prone
to changes in ctags parsers, the patch also performs some consistency
checks:
* whether the parser number in ctags/TM matches
* whether for the given language the tag type number is identical in TM
mapping and ctags definition
* whether all tag types defined in ctags parser are mapped in TM and in
reverse, whether all mapped tags in TM are defined in ctags parser
* whether there aren't duplicate tag types
Unfortunately the checks are possible only for parsers not using regex
because regex definitions are not exposed by ctags (TODO).
A bonus side effect of the changes is we can now use real tag types defined
for each languages in ctags when parsing ctags tag files instead of
using the hard-coded static values which mostly work just for C/C++.
At the same time ignore tags of the type tm_tag_undef_t when parsing -
we cannot query them anyway and this eliminates the need to call
tm_tags_extract(source_file->tags_array, tm_tag_max_t);
when creating tags file.
At the moment it is a bit hard to distinguish which of the functions
we are using belong to ctags. To make more explicit what we need
from ctags, wrap all ctags-related code and access ctags only using
this layer.
The interface from tm_ctags_wrappers.h can serve as a base for
proper ctags interface if ctags becomes a library.
This patch moves code related to reading/writing various tag file formats
into form TMTag and TMWorkspace to TMSourceFile. The benefits of this
change are:
* only tm_source_file.c interfaces with ctags after this change
* tagEntryInfo is removed from headers, no redefinitions needed any more
* source code is more evenly distributed among tm_source_file.c,
tm_tag.c and tm_workspace.c after the change (tm_tag.c got smaller)
* all tag reading/writing is at a single place
Despite its size, this patch mostly just moves code. Notable changes are:
* tm_tag_new() now creates just an empty tag. The tag is filled by various
init_* functions inside tm_source_file.c
* there are new functions tm_source_file_read_tags_file() and
tm_source_file_write_tags_file() - these hide tags file
reading/writing details from tm_workspace.c
* tm_source_file_write() debugging function got removed -
tm_source_file_write_tags_file() does a similar thing and there's no
need to keep around two functions doing the same.
The direct python parser -> tagmanager callback is rather hacky
and unnecessary as we can do the same in the normal ctags callback
upon receiving a tag.
Closeuniversal-ctags/ctags#453.
(This is about a bug spotted in universal-ctags/ctags#453 by @mislav and
in universal-ctags/ctags#11 by @NewAlexandria.)
Kinds C and d are for Rspec.
Parts of code related to above kinds assume a ruby string
comes after Rspec keywords (describe or context).
This is a wrong assumption. A class name can be used there.
It is nice if ctags can handle these rspec code well, but we
don't have enough resource to make it now.
So in this commit I delete rspec related code temporary. I
just reserve a kind letter 'd' for rspec for the future. 'C'
is completely deleted because (1) describe and context have
the same meaning in rspec, and (2) we would like to assign
'C' for Ruby constant as ripper-tags does.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
This patch is intended a bug reported as sf.bug:364.
https://sourceforge.net/p/ctags/bugs/364/
Writing a test case is helped by Dmitry Gutov.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
fuzz target reports canMatch access wrong memory
area when php-anonymous_functions.d/input.php is
given as input.
This patch fixes it.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Because of the missing "typedef struct TMFoo" it was missing from the gtkdoc
header (the struct listings are always without typedef). This is also
consistent with the rest of geany.
@gironly for TMParserType so it's picked up as well.
Based on 21e74e6a019975045a7975bc611ae63f0917f976 from universal-ctags,
and update the tests accordingly, thanks to @JX7P.
Closes#940.
X-Universal-CTags-Commit-ID: 21e74e6a019975045a7975bc611ae63f0917f976
We should isolate ctags from Geany completely and use separate types. At
the moment langType is shared by both Geany and ctags. For Geany redefine
it as TMParserType (which was currently used as the name of the enum and
was unused) and use everywhere in Geany. At the same time convert some
ints to TMParserType where they denote the parser.
This is strictly speaking an API change but no plugin uses langType at the
moment so its renaming doesn't cause any problems.
The only remaining visible ctags type is tagEntryInfo - it is however
used only inside tagmanager (and can be later removed quite easily too
by slightly reorganizing TM source files).
At the moment the Geany code uses arbitrary combination of the following
synonyms
TM_PARSER_NONE / LANG_IGNORE / -2
TM_PARSER_AUTO / LANG_AUTO / -1
Especially using just the numbers makes things very confusing.
In the Geany code this patch replaces all occurrences of -2 and LANG_IGNORE
with TM_PARSER_NONE. It also removes LANG_IGNORE from the header which
isn't needed any more.
In addition, TM_PARSER_AUTO/LANG_AUTO shouldn't be used at all. We want
filetype detection based on Geany's definitions and not based on the
hard-coded ctags definitions. Remove it completely.
Finally, as it's clearer now what the constants mean, the patch fixes the
implementation of langs_compatible() (tag or file can never be of type
AUTO but we should rather check for NONE filetypes which we should
consider incompatible between each other).
Pop up scope completion dialog for namespaces too; e.g. for
boost::
show all symbols defined in the namespace. Determine whether the namespace
scope completion should be used based on whether user typed a scope
separator. If so, perform completion for namespaces before normal scope
completion - this seems to work better e.g. for Scintilla where
Scintilla::
would otherwise pop up the varible sci instead of showing everything
in the namespace (might be more questionable for languages where
the scope separator is identical to the dereference operator like
Java's "." but we have to make some choice anyway).
The performance seems to be reasonable - for the completion all tags
have to be walked but after testing with big C++ projects like
boost and Mozilla, the completion takes only something like 0.2s
which is acceptable as the delay happens only on typing the scope
completion separator and feels kind of expected.
Also tested with linux kernel sources which normally lack any scope
information by hacking TM a bit and injecting 10-character scope for
each tag - then the completion takes something over 0.5s.
We only perform search based on variable name so if a variable is e.g. of
the type std::Foo, we can drop the std:: prefix and search only for the
Foo type.
This is far from perfect and contains a lot of guessing. It showed
good results based on our tests cases, fixing several issues and not
introducing any more issues (admittedly, after working around a subtle
one regarding D static ifs).
Closes#845.
