Re: [Anjuta-list] RFC: Generic tag-utils lib
- From: Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>
- To: anjuta-list lists sourceforge net
- Subject: Re: [Anjuta-list] RFC: Generic tag-utils lib
- Date: Fri Sep 21 06:50:02 2001
Timothee Besset wrote:
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.
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.
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.
- 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.
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
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.
- 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.
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.
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..
Anjuta-list mailing list
Anjuta-list lists sourceforge net
] [Thread Prev