[Geany-devel] tagmanager changes

[Nick Treleaven]

On 27/04/2012 06:30, Lex Trotman wrote:
> [...]
>>
>> I don't understand why tagmanager has to be replaced, why not just replace
>> the parts you want to improve? Rewriting it is likely to lead to a new set
>> of bugs and be hard to review and merge changes from master.

> One of the problems with tagmanager is its complexity, leading to
> considerable wariness on the part of many of us about changing it
> since we don't understand what we might break.

I don't see this myself, I see some complicating issues which could be 
resolved (and I'm willing to work on them), but generally a sound design 
for what it provides and for extra things we may want to add.

> Actually documenting the overall structure of tagmanager and how it is
> supposed to work would be a good thing, whats a workspace? what is it
> meant to represent, how are scopes represented? etc.

Isn't it clear from the data structures? Look at TMWorkspace. Scopes and 
other tag metadata is the same as CTags. Obviously if we had at-a-glance 
overall documentation that would be good.

One confusing thing is that a TMTag can be used for an actual tag or for 
a file. Probably that could be cleaned up.

>>>    - a "multi-cache" one that, as its name suggests, maintains multiple
>>>      caches (sorted tags arrays).  it uses a little more memory and is
>>>      slower on insertion since it maintains several sorted lists, but a
>>>      search on an already existing cache is very fast.
>>
>>
>> Won't this be slow for adding many tags at once? How is this design better
>> than tagmanager?
>
> Perhaps Colomban could confirm, but my first thought is that this is
> for nested scopes.

I expect the design is better in some respects (and to be fair I didn't 
look for better things), but finding a tag based on its name is 
something we are always going to want to be fast. Even for scope 
completion, you still need to lookup a tag structure from a name string. 
So I think we will always want a sorted array of tags per document that 
we can bsearch (or something equally fast).

Also, I've probably sounded quite harsh on Colomban's design, but I'm 
commenting on what I think is important. I am genuinely interested in 
why his design decisions are better. It's a lot to take in all at once, 
so probably needs some explanation. Sorry if I didn't make that clear.

> How does tagmanager handle nested scopes, or how would it need to be
> modified to do so, considering the example (in C)
>
> { 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 */
>    { struct c o;
>      o./* struct c members */
>      p./* struct a members */
>    }
>    o./* struct a members */
>    p./* struct a members */
> }
>
> How much needs to be changed in tagmanager so that the right
> autocompletes can be provided at each comment?  (assuming c.c is
> taught to parse local variables of course)

I don't know, but we still need fast tag lookup based on name. If O(n) 
scope lookup is too slow, we will need additional data structures 
arranged differently, but whatever we have should have something like 
O(log n) lookup for names as this is by far the most common operation.

>>> * this "backend" abstraction might be really overkill, and maybe we
>>>    could do better without it?;
>>
>>
>> I don't see why having two is better. The memory overhead for a pointer
>> array is not much vs. the size of the tag structures. Fast searching is
>> important.
>>
>
> It is but is it flexible enough to be expanded to nested scopes.

see above.

>>> * tags (and most types) are reference-counted (so they aren't
>>>    necessarily duplicated, e.g. in the multicache backend);
>>
>>
>> I don't really understand src/symbols.c since the real-time parsing change,
>> so don't really understand why this is needed.
>
> Blame C++ and overloaded names I think.

I looked at the thread about that, and from what I could tell, the 
problem was for reparsing unsaved files. Wasn't the order OK for files 
that have just been saved? (Also I don't follow what that has to do with 
reference counting).

>> I don't really see what the problem understanding it is. I thought scope
>> completion was just tm_workspace_find_scoped and related functions, not some
>> tagmanager-wide problem.
>
> I think the fact that this isn't clear is the problem :)

If I'm following you correctly, I think you're saying the design needs 
to change, which I accept may be true. What I was saying was that 
understanding the existing code for scope completion is not really that 
complex.

Regards,
Nick