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

[Naba Kumar <kh_naba yahoo com>]

On 22 Sep 2001 12:42:28 +0530, Biswapesh Chattopadhyay wrote:
> Hi all
> 
> This is basically an update on my previous posting in which I proposed 
> to integrate the tag manager, ccview, ctags and scintilla's calltip and 
> autocomplete features based on a common set of libraries. So far I have:
> 
> a) Modified ctags so that it outputs filepositions and function/macro 
> prototypes and sent the patch to the ctags maintainer.
> b) Written a small tag-utils class to parse the ctags-generated file 
> (with the added attributes) and to use this for the basis of 
> autocomplete suggestions and calltips (not integrated with Scite (just a 
> text-based interface) but a few mods to aneditor.cxx and text_editor.c 
> should fix that).
> 

Well, in the interim, I would like to tell you that we don't have
to (and shouldn't) make any tight integration of the TagsManager
 with the other components such as aneditor, ccview etc.

Just consider it as a different project. You maintain a database of
Tags (preferably in a hash) and provide apis (functions calls) to
manupulate/query the information.

The module must be completely sheilded from the outside world and there
should not be any reference to the external application (execpt for the
utility functions, which will be available in libanjuta in anjuta2).

Go for a GtkObject based design. It is a very good way to create
objects, later we will bonobofy it and then plug into anjuta2 as
component.

Once the tags manager widget is ready, we can use it with the current
anjuta in whatever way we wish through the apis. The respective modules,
like aneditor, ccview etc will need to be modified to use the
TagsManager widget.

> However, there are numerous problems with this approach:
> 
> a) The basic aim of ctags differs from what we want to do here - it 
> needs to maintain vim/emacs compatibility and is basically meant for 
> browsing, whereas we aim to use it for symbol autocompletion and 
> calltips as well.

Right.

> b) ctags has a file oriented approach whereas for maximum efficiency, we 
> would like to generate tag info from a buffer whenever possible.

That's a nice idea, but the point is we will also need to track the tags
of files which have not yet been open. So, it make sense to provide both
the interfaces scan_from_file() and scan_from_buffer() or something
similar. 

Also we will need to cache the data (the xml file format currently in
use in class browser is a good way to cache it), so that we don't need
to scan the unmodified files everytime. This will increase the
efficiency very much.

> c) It is difficult to control ctags properly since it does not have a 
> clear interface.

> d) ctags has no support for pre-processing, something I've found is 
> essential for complex projects (Try running ctags on 
> /usr/include/stdio.h for example, you won't get any tags for 'fprintf')
> 

> Given the above, my proposal is to extract the relevant parts of ctags 
> (mainly the combined c/c++/java parser) and write a generic library 
> which will give us the combined functionality of workspace manager + 
> source browser + symbol autocompletion/calltip + maybe context-sensitive 
> help as well.
> 
> What do the developers feel about this ? We can make this into a generic 
> library so that other people (WxWorkshop and GIDE, for example) can use 
> this as well. In my estimate, it would take around a week to extract the 
> relevant parts of ctags (c++/java parser) and make a library of it. I am 
> willing to do the groundwork and prepare the backend (I'm no good at GUI 
> stuff :-() and write the generic library, however, it would be nice if 
> someone could help me by reviewing the interfaces since I do not know 
> the requirements/long-term plans for Anjuta.

Great, but you must be careful with it if you wishes to build a seperate
library. Make it independent of the TagsManager. Let TagsManager
interact with the library/scanner through a set of API.

Also make sure the parsers, you might be using (c/c++/java) are
extensible, ie in future, if somebody wishes to a parser for pascal,
then it should be just plug-n-play thingy.

You don't have to wory about the GUI stuffs. Neither the library nor the
TagsManager should have any provision for GUI. They will be non-gui base
objects. They will provide only a set of interfaces (apis) to the
external world.

The class-browser, the editor, project manager etc will only interact
with the given set of interfaces and no more than that.

Well we can picture this way (I am not a good artist though :-)

+----------------------------------+
|  Underlying Tags Parser library. |
+----------------------------------+
              /   \
              |   |
              |   |
              \   /
+-----------------------------------+
| TagsManager [based on hash table  |
|     for efficiency  and caching   |
+-----------------------------------+
         |         |         |
         |         |         |
       +----+   +----+    +------+
       |    |   |    |    |      |
       +----+   +----+    +------+
          (Other components)



I hope that's a good drawing. :-)

> 
> Biswa.
> 
--

Regards,
-Naba

-------------------------------------------------------------
If you do something right once, someone will ask you to do it again.
-------------------------------------------------------------



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com