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

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.



Anjuta-list mailing list
Anjuta-list lists sourceforge net

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]