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).
For instance for the boost library this makes the resulting string passed
to scintilla 6x shorter. Because scintilla goes through this list more
or less linearly for every single word in the document, this can bring
significant reductions of time spent when recolorizing.
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.
For users a tag is <this> so the naming can be confusing.
The only exception where we probably shouldn't use the word symbol is the
"tags file" (*.tags) containing global tags - this has already the "tags"
extension and is more related to ctags and using "symbols file" is a bit
strange in this case.
As a result, the only places where this patch leaves the word "tag" are:
* phrase "tags file(s)"
* phrase "tags parser(s)"
* documentation mentioning the "tags" directory
* documentation mentioning the *.tags extension
and of course where it means the HTML/XML markup <thing>. The rest of the
uses of the word "tag" is replaced with "symbol".
Documentation is updated accordingly.
Fixes#579.
748137bd1dfa648948d9d127aa3e27b6857db764 improved return types, but as
this test case was added in parallel it wasn't updated as needed for
the new, more correct, results.
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.
