Re: [Anjuta-list] RFC: Generic tag-utils lib

[Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>]

Timothee Besset wrote:

> I am not very familiar with ctags, so I don't know how well it fits with what we want to do. But I'd like to pin point a few important things about maintaining a program database for autocompletion and code browsing.
>
> - ctags may not be the only solution? Have we looked at other tagging / indexing libraries? There may be more interesting/adequate libs around already.
AFAIK, the contenders are ctags, freescope (or cscope) and GNU Global. 
Global and ctags are vitrually the same, though global has utilities to 
find tags as well (this part is trivial to implement and I've already 
written it). However, ctags is more widely used (vim/emacs) and is known 
to work. Freescope is limited to C, is mainly an x-ref utility, and 
comparatively new. If anyone knows any other tool/library, I'd be very 
interested to hear about it.

> - how/when is ctags called? you might want to let the user decide a few things as far as when ctags should be called. on low end boxes, you might want to update your program database only when the user explicitely requests it. in other cases you would do that each time a file is saved. if you have lots of CPU, you might want to update each time the editing buffers are changed.
Currently, ctags is called from within tags_manager.c to generate symbol 
locations (file, line). This, of course, limits it's utility to tag 
browsing. In the current code, autocomple is implemented by looking for 
symbols that match the typed value within the file, and calltips are 
implemented using a static global database (linux-gnome-c.api) which 
comes with anjuta and is generated by running a python program on the 
output of ctags.

As you rightly point out, we need to optimize on a case-by-case basis 
depending on user preferences, etc. This is of course the main problem 
with using ctags and cpp as independent programs using fork()/exec() or 
popen() - it slows things down dreadfully. Further, since ctags is 
currently limited to operating on files, it is virtually impossible to 
update browser dynamically since it requires parsing of the editor 
buffer (maybe we can have a background thread which takes snapshots of 
the current buffer at fixed intervals and update the source browser 
accordingly).

> - in cases where the browsing information has been generated from files and the current editing buffers are not the same (i.e. a few lines added / removed), then we need to have some mechanism that can get you the actual line numbers from the initial files line numbers.
This is pretty tricky and needs very close coupling with the editor. A 
better option probably is to re-generate tag info on each save and load, 
and is time between saves exceeds a certain limit, then take a snapshot 
of the buffer and update the tags based on that.

> That's all I can think about for now. Obviously, we might want a simple and self contained solution first, and then work on incremental refinements of the system. I usually write down on paper the features I WANT, and the features I PLAN to add, then start the implementation..
Thanks for the suggestions - I'll probably start with a simple 
standalone implementation of the backend (keeping the above in mind) 
based on the ctags C++ parser and post it on the list sometime in the 
coming weeks, unless someone beats me to it.

Regards.
Biswa.

> TTimo
>
>
> ______________________________________________
> Anjuta-list mailing list
> Anjuta-list lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/anjuta-list