Re: [Anjuta-list] "On the fly" symbol lookup [LONG]

[Biswapesh Chattopadhyay <biswapesh_chaterjee tcscal co in>]

I initially considered extending ctags. I already have a patch against
ctags 5.0.1 which adds generation of argument list for functions and
macros with arguments and file positions along with line numbers. I also
have a (command-line) implementation of a client that can use the file
generated by the patched ctags to:

a) Provide global autocompletion list.
b) Show argument list for given function.

The above was quite trivial to do. Unfortunately, as I explained in this
list before, it has several problems. My current plan is, therefore, to
take the C parser from CTAGS (it does C++ and Java as well) and use
Berkeley DB (it exists on virtually every Linux machine and is used by
evolution, et al) to combine the functionality of Ctags,
autocomplete/calltips, project browser/manager, etc. I am thinking in
the lines of a client-server approach where the server:

a) On first invocation of anjuta, indexes all the system headers
recursively (/usr/include, /usr/local/include + user specified list of
directories) and creates the global symbol list. This is similar to
ctags but will include my extensions such as argumnent list generation,
etc. This, of course, can be optimized by generating such a list
globally during the installation stage - but that is a different issue.

b) On opening of a project, scans the top-level project directory
recursively for C/C++/Header files and generates a project-specific
symbol list (trivial: dirent, etc). This can, of course, be optimized
using timestamps and stuff, but that should be easy to add-on later. We
can also consider integrating the stuff with the project manager so as
to get the revevant list from the porject manager, or, failing that,
from Makefile.am of each directory. This would have the side benifit of
enabling us to load a project created by another IDE (or without an IDE)
without the user having to import each file individually.

c) On opening of each file in Scintilla, handles it a list of symbols
for highlighting (note that Scintilla currently has four different
keyword lists for highlighting, we currently use one. I am exploring how
we can use the other three - this will probably be trivial).

d) On getting the relevant messsage from Scintilla, use (a) and (b) to
supply it with symbollist/calltips. The order, of course, would be local
followed by project followed by global. Duplicates would also be
resolved in the same order.

e) The generic C parser can also be used while loading a file/project to
show the symbol list on the left-most pane as now for easy navigation.

The role of the client will be to pass on requests to the server using a
standardized API and marshall it to Scintilla/Project-browser/etc.

This is roughly my plan. Currently, unfortunately, this is at a planning
stage, but I'm planning to start earnestly on it in a day or two.

I'm more than open to suggestions since this is my first effort towards
contributing to an OpenSource project and I know zilch about
GTK+/GNOME/Autoconf, etc (in fact one of the reasons for delay is that
I'm reading up of those stuff :-) I also have very little experience
with IDEs, being primarily a UNIX/C/Oracle developer.

Rgds.
Biswa.

On Mon, 2001-10-01 at 20:27, Timothee Besset wrote:
> On 02 Oct 2001 18:17:05 +0530
> Biswapesh Chattopadhyay <biswapesh_chaterjee tcscal co in> wrote:
> > 
> > I've just started on a generic code-completion and calltips module (the
> > current one is hard-coded) - let's see how far I can get.
> > 
> > - Biswa.
> > 
> 
> What are the main features you are planning for that? I kind of consider
> that good code browsing requires some database-like functionalities. Are
> you going to extend CTags? Or write something completely from scratch?
> 
> regards
> 
> TTimo
> 
> _______________________________________________
> Anjuta-list mailing list
> Anjuta-list lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/anjuta-list