Fix the symbols tree hierarchy by considering the whole scope when
adding a tag, avoiding choosing the wrong parent when several tags have
the same name. Until now, to avoid such misbehavior we only used to
choose the parent candidate that appeared last (line-wise) before the
child. It works in most typical situations as generally tag names are
fairly unique, and children appear right after their parent.
However, there are cases that are trickier and cannot be handled that
way. In the following valid C++ snippet, it is impossible to know
whether `function` should be listed under the namespace `A` or the
class `A` without looking at its full scope:
```C++
namespace A {
namespace B {
class A {
void method() {}
};
};
void function() {}
};
```
And it is a real-world problem for some parsers like the JSON parser
that generates numeric indices for array elements name, often leading
to several possibly close duplicates.
Additionally, to prevent trying to set a tag as its own parent, the
code guarded against accepting a parent if the child had the same name,
lading to incorrect hierarchy for `method` in cases like this:
```C++
namespace A {
class A {
void method() {}
};
};
```
So to fix this, consider the whole hierarchy of a tag for choosing its
parent, when that information is available from the parser.
Fixes#1583.
Since the Scintilla C++ lexer started to fold on `()` [1], the code
looking up the current scope is confused whenever the function
signature spans multiple lines. Fix this by skipping fold levels that
correspond to parentheses.
Fixes#1279.
[1] https://sourceforge.net/p/scintilla/feature-requests/1138/
imported in 24f91981c057a7e212c09da66fb974c3ccc85bd6
At the moment tags with identical names are stored into a linked list in
tags_table and parents_table. This however leads to quadratic complexity
when looking up the nearest parent or tag in tree because the whole list
has to be traversed.
Use binary trees indexed by line number instead of lists so the lookup can
be performed in log(N) time and the overall complexity is N*log(N) instead
of N^2.
The GTree API is a little stupid because during the search it doesn't give
access to the value and it doesn't tell when a leaf node was reached. For
this reason the lookup has to be made in two steps - first, the best line
number is found (returned in user_data) and then a normal search for the
found line number is made to get the value stored in the tree.
This patch fixes the problem described in #577 when e.g. a big json export
file contains many identically named tags.
Even when we know when should be searching for definition (or declaration),
we can keep searching for the opposite type too when we didn't find
anything with the "correct" def/decl type. So at least we find "something"
of that name.
* always filter-out symbol from the current line from the list
* when clicked on a symbol on the current line always swap
definition/declaration search even if there are more symbols from the
current search direction
Fixes#950
For instance when performing goto tag for Foo and Foo is defined as
typedef struct Foo {} Foo;
go immediately to the struct location without showing the goto popup with
both the struct name and typedef. When there are more occurrences of the
name, filter the list and don't show the synonyms in the popup.
In addition, if the cursor is on the same line as the typedef, go to
the struct and vice versa.
Note the missing
g_strcmp0(second->var_type, first->name) == 0
in the check - in this particular case we won't get the type to which the
typedef refers inside var_type because at the time the typedef tag is
generated in c.c the struct tag doesn't exist yet. On the other hand
there's no second->var_type == NULL either because this behaviour seems
to be rather implementation-specific and might easily change in the
future. The existing checks are probably sufficient for the real-world
code.
It could arguably not be translatable and only `filename:line` display,
but as we have already a space on the right of the colon it's not, and
allowing translation is not a problem and can give better localization.
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).
The x coordinate is now taken from the scintilla caret position. However,
when performing ctrl+click, we have to distinguish two cases:
1. the click happens in the second half of a letter - in this case the caret
is placed behind the letter and the popup appears behind it - no problem
2. the click happens in the first part of a letter - caret is placed before
the letter and the popup appears before the position where the click
happened - this means that the mouse cursor is above the popup which causes
that the mouse cursor highlights the item at the position of the cursor
instead of having the first item in the menu highlighted.
The patch calculates offset between caret and the mouse click event
position and uses this value to adjust the popup positioning so it's
outside the mouse cursor.
Even when the user Ctrl+clicks to perform goto tag definition, it should
be possible to select the item from the list using keyboard (and have
the first item automatically selected so ctrl+click plus enter afterwards
always gets you somewhere).
If only a single tag is found, just perform the goto. If more tags are found,
show them in a popup. Try to help the user find the right file by
putting the "best" tag at the first position and emphasizing it.
Thanks to Colomban Wendling for various improvements of this patch.
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.
Do the same with struct/class/union... member tags as we do with
typenames - extract them from the edited file and merge them with
the array containing all of them so while editing, there should
be no slowdowns because one file usually doesn't contain so many
tags. This eliminates about 2s freeze when typing "." on a linux
kernel project with 2300000 tags.
Extract typename and member tags also for global tags in case someone
creates a giant tags file - this needs to be done just once when
loading the tag files.
All the remaining tm_tags_extract() in Geany are called on
file tag array only so there shouldn't be any performance problems.
When profiling Geany I/O activity, there are lots of I/O operations happening
when just typing in the editor caused by the updates of the symbol tree
and loading the icon files.
In addition, in the case of tag_other the leaves of the tree use
classviewer-var instead of the parent icon (e.g. with enums). In this case
the icon is loaded from the disk every time it's requested which takes
about 70% of the tree creation time when the tree consists only of such
nodes.
To fix these problems load the icons once and return the loaded icons when
requested instead of reloading them from the disk all the time.
The tree model nodes consist of GNode structs:
struct GNode {
gpointer data;
GNode *next;
GNode *prev;
GNode *parent;
GNode *children;
};
where children are a linked list. To append a value, the list has to be
walked to the end and with nodes with many children (which is our case)
this becomes very expensive.
We sort the tree afterwards anyway so it doesn't matter where we insert the
value.
gtk_tree_store_set() becomes very slow when the tree gets bigger
because internally it calls gtk_tree_store_get_path() which counts
all the entries in a linked list of elements at the same tree level
to get the tree path.
Avoid the call of this function when not needed.
Because function return types are not used to determine tag equality,
we need to also update the tooltip of an existing tag otherwise the return
type doesn't get updated when changed.
