[Geany-devel] tagmanager changes

[Colomban Wendling]

Le 29/04/2012 14:07, Nick Treleaven a écrit :
> 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.

What I personally blame TM for is not the data structure or overall
design, but the code.  I can't get my head around the implementation.
Every time I try to get it, I get a headache and generally no fix :(

But maybe I'm just plain stupid, or maybe I just miss one or two key
things of how it's written to get it.

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

Agreed, that's something I think that should be quite easy to "fix" and
that would make the thing easier to understand at first (though it's not
one of the things that makes me not understand TM ;)).  BTW, do we
actually use any file tags?

>>>>    - 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.

Don't worry about sounding harsh or something, I totally agree that
changing for changing is not a good idea.  To be honest, there were
really two reasons why I tried to write a new tagmanager on the first place:

1) because I wasn't able to fix the current one;
2) to support asynchronous parsing.

And actually I haven't added much great design, it actually works quite
the same as does TM currently -- per-file tags, a workspace holding a
merge of all tags.

> [...]
> 
>>>> * 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).

We don't parse unsaved files at all because TM can't do that.  And
that's once another thing that should be fixed.

However I don't get the point you're talking about, maybe my answer is
OT then.


Cheers,
Colomban