[Geany-devel] tagmanager changes

Colomban Wendling lists.ban at xxxxx
Sun Apr 29 14:55:42 UTC 2012

Le 27/04/2012 07:30, Lex Trotman a écrit :
> [...]
>>>   - 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.

Not at all, sorry :)
It's only for performance, so search on different criteria can remain
fast (just a bsearch()).

> 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)
> And of course the same question for Colomban.

To really support such thing would require the parsers to provide a true
tree, not a flat thing.  However, my scope completion "algorithm" takes
into account a few things to try to find The Right Thing™:

1) the file in which the tag appears (e.g. tries to resolve things
locally first);
2) the "distance" in lines between the tags (e.g. the tag that comes
just before the one to complete has precedence over another one).

but this wouldn't be enough to get correct results with your example; it
would really need a tree.


More information about the Devel mailing list