This is mostly just moving code with just some minor modifications:
- removal of code of unsupported platforms (VAX, OS2, etc.)
- syncing includes/headers of affected files with uctags
- removal of some functions we don't need in Geany and whose movement
would require additional changes (those will get added back when
doing final sync with uctags)
- minor whitespace syncs
The usage in lregex is hacky (casting const char * to char *) but it's
the quickest way to implement it right now (the question is whether
we shouldn't revert back to POSIX regex and simply use the uctags
implementation).
This is more reliable than using `which`, which doesn't work if the CXX
environment variable is set to something else than an executable (e.g
contains options), and is apparently less portable on some systems.
See:
* http://lists.geany.org/pipermail/devel/2009-September/001367.html,
which lead to 5bb28825aadb43ea8ba536c34970d53860b50759.
* https://sourceforge.net/p/geany/bugs/455/, which lead to a revert
of the above, 5b9605a9d6d799629b8ed3163596069c8c948b06.
Fixes#829.
This patch basically just replaces
sInputFile.name -> sInputFile.input.name
sInputFile.lineNumber -> sInputFile.input.lineNumber
plus some minor related stuff.
This was done using Geany's "replace tabs with spaces" followed by
"replace spaces with tabs" plus a lot of manual work because the
indentation was inconsistent in many cases.
Basically just the stuff I added to uctags to improve hashing of keywords.
This patch drops some extra stuff from uctags we don't need at the moment
and which would require changes in other files.
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.
