[Geany-devel] tagmanager changes

[Lex Trotman]

On 8 May 2012 02:04, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> On 02/05/2012 05:46, Lex Trotman wrote:
>>
>> 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?
>
>
> documentation bug IMO

O-K, clearly the documenter obviously had a meaning for the term in
mind since it occurs in several places, what do you think they meant?

>
>
>> - its not clear how it all goes together, the workspace contains
>> global tags and work_objects, or is that files and whats the
>
>
> workspace work objects are document tags. global tags explained in geany's
> manual.

And the work objects/document tags are in a different array to global
tags if I read your comment on the next post right?

>
>
>> difference between source_file and file_entry?
>
>
> It doesn't look like tm_file_entry_ is really used.

Along with your comment below and about project on the next post,
sounds like tm code could be reduced significantly.  Might help :)

>
>
>>
>> - similarly whats the difference between symbol and tag?
>
>
> tm_symbol_ doesn't seem to be used.
>
>
>>
>> 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?
>
>
> no

So what did you mean?

>
>
>>
>> - 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.
>
>
> the gain in simplicity makes a bigger array to search worth it. Remember,
> global tags aren't included in the workspace array of tagmanager, so we're
> not talking a big number of tags, and we have o(log n) searching.
>

Ok, but to date document tags don't include local variables (see
below) so they will add many more names, with lots of replication.

>
>
>> 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.
>
>
> ctags c.c already parses local tags

No it doesn't AFAICT:

on brace open createTags() calls tagCheck() and nest(),

on brace open checkTag() only makes a tag for a preceding function or
contextual entity (== class, enum, namespace struct or union) it does
not look at the contents of the {},

and nest() only recurses if the { opens a class, enum, namespace,
struct, union otherwise it skips everything in the {},

so no local declarations are parsed unless I've missed something?

>
>>
>> 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)
>
>
> If you're talking about master, I think I still experienced wrong parenting
> on reparsing when removing lines.

HEAD of master gives me no stability problems with C++, can't cause
any problems with C either, can you reproduce?

>
>
>> 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.
>
>
> I don't think I suggested moving functionality.

OK, I read it that you were suggesting that.

I wondered whether TM could
> help make symbols.c less complex. I would need to understand the complexity
> to know whether this is appropriate or not.
>
> Titanic comment is bizarre. My suggestion could equally apply to
> ctagsmanager.

Oh dear, misdirected attempt at black humor failed :(

Though I thought my UK friends used the term "shuffling the deckchairs
on the titanic" to mean irrelevant changes.  Maybe they learned it
from me.  But if you were not meaning to move stuff from symbol.c to
tagmanager then I guess the implication that just moving stuff doesn't
reduce complexity wouldn't make sense either.


Cheers
Lex

>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel