[Geany-devel] tagmanager changes

[Lex Trotman]

Hi All,

To summarise since the thread has several subthreads.

1. Tagmanager Understandability

a. I generated the doxygen documentation for tagmanager, it works if
you set recursive, but didn't help much:

- if its not OOP why does it say things like "TMWorkspace is derived
from TMWorkObject" and similar?

- its not clear how it all goes together, the workspace contains
global tags and work_objects, or is that files and whats the
difference between source_file and file_entry?

- similarly whats the difference between symbol and tag?

2. Ability to expand tagmanager to handle names declared in lexical
scopes (not to be confused with struct/class scopes).  Here is the
example again with some numbers so I can refer to them

{ struct a o; struct a p;
    o./* struct a members */
   { struct b o;
     o./* struct b members */
     p./* struct a members */
   }
   o./* struct a members */
   p./* struct a members <1> */
   { struct c o;
     o./* struct c members */
     p./* struct a members <2> */
   }
   o./* struct a members */
   p./* struct a members */
 }

a. yep, tries use more memory than an array, the usual speed/space,
pick one, tradeoff :)

b. @Nick, when you say sort by scope then name, are you wanting to
have an entry in the table for each declaration of the name?

- If so this makes the array much bigger to search and your search
speed depends on size, and it doesn't get you anything, you can't
search by scope since you don't know if the name is declared in the
scope you are in or an outer scope compare p at <1> and <2>

- having a single name array which then points to scope info for the
name is a viable approach (disclosure, thats how I'm doing the symbol
table for a language I'm developing) but the table being searched is
usually larger than if you have nested arrays.  Being smaller these
are faster to search if the search isn't O(1), hence the suggestion of
trie instead of bsearch.

3. Background/asynchronous whatever you want to call it parsing

a. @Colomban, you say that caches are created on first lookup, doesn't
that throw work back into the UI thread which could have been done in
the parsing thread?

4. Ctags parsers

Agree with Nick that the parsers are usable, but if we start modifying
them to handle local declarations then they will be totally
incompatible with the Ctags project so I guess it doesn't matter other
than for getting languages we don't currently parse.

5. Overloaded symbols

Since Colombans patch, overloaded symbols are now stable for all
practical code (I think theoretically it could get confused if the
overloads are on the same line but thats unlikely enough to ignore for
human generated code)

6. Moving functionality from symbols.c to tagmanager

a. Since its the 100th anniversary of the Titanic sinking, I think
that "shuffling the deckchairs" is an apt analogy, the functionality
has to be somewhere, its only useful to move it if the destination
significantly reduces the effort required.

Cheers
Lex