Re: [Anjuta-list] Symbol Name generation from file for autocomplete/calltip [LONG]

[Naba Kumar <kh_naba yahoo com>]

On 12 Sep 2001 10:33:41 +0530, Biswapesh Chattopadhyay wrote:
> OK, I went through the code and the relevant function seems to be this:
> tags_manager.c:606 update_using_ctags (TagsManager * tm, gchar * filename)
> 
> you're right, it does almost the same thing.
> 
> However, AFAICS, there are a couple of minor problems:
> 
> 1) It only extracts the "local" tags for the file which means that you are 
> handling the global calltip/autocomplete using linux-gnome-c.api and the 
> local tags with tags.cache. This is probably because the function is not 
> pre-processing the file for the included files, which was the original 
> problem.
> 
> 2) Anjuta is probably not using this file for anything apart from 'symbol' 
> auto-completion. The original poster's suggestion (if I understood him 
> correctly) was that autocompletion, calltips and perhaps keyword highighting 
> should depend on the included files, and it should work irrespective of 
> whether the header is a system header or a local header. In order for this to 
> work correctly, we need to:

>     a) Pre-process the file on a periodic basis (maybe on each save ?) with 
> the project-level compiler settings for include directories, defines, etc.
>     b) Run ctags on the pre-processed file and extract all symbols and, for 
> functions, prototypes and macros, the definition and store these in the 
> TagsManager struct for that file/project.
>     c) Use this for auto-completion, calltips and maybe even syntax 
> highlighting (instead of hardcoding those in Scintilla's properties file).
>     d) Do away with the system level API file with hardcoded definitions.
> 

You are right. The current tags implementation is only used for tags
browsing and not for autocompletion or calltips. What I meant earlier is
that a similar function, though not as good as yours, is already there
in the source.

Your idea about extracting the tags and using it for the autocompletion
and calltips is very needed feature. And thank you that you will help
implementing it. I am laying out a few tips that may become handy.

Currently, Anjuta scans two times in a file, one for browser tags and
other for ccview. Both the things basically does the samething (with a
silght difference though). So, I think they could be merged in a single
scan. This single scan will scan the file and extract all possible tags
informations.

Now, the current tags manager is tightly coupled with the tags browers.
First we need to separate them. We will need to have a generic (means
applicable to everyone). TagsManager class. This class will store all
the tags that have been scanned in a proper database format (internal)
and also take care of caching (external) the results, so that we don't
need to scan the file every time. Like, currently implemented, we can
use the timestamps to decide for the scan.

Once the class is ready, then:

1) We modify the current tags browser to work with this new TagsManager
class.

2) We also modify the ccview class to get the tags from this TagsManager
instead of going for it's own scannings.

3) We modify some codes in aneditor.cxx to load the API information from
the new TagsManager. Currently, it only loads the static global API
file. What we can do to implement this is:
    a) Load the global static file.
    b) Get the tags relevent to this file (file open in the editor) from
the TagsManager
       and convert it into the approriate format for the API in a char
buffer.
    c) Load this local API definition in the editor.


Current TagsManager is very inefficient, because it uses list for the
datasturcture. The new TagsManager should use a hash to speed up
processing. Also we will need to change the way things are stored in the
TagsManager for generic purpose.

Later, we can even implement other tags related features easily, if we
have this generic TagsManager.

The TagsManager should store all the information for all the files in
the project, if anjuta is in project mode. Otherwise, it should store
only the information for the opened files (and the files included by
them).

> AFAICS, there are two ways to go about it:
> 
> a) Pre-process each file fully and extract all symbols/definitions from it.
> b) 	Extract the header file names for the file.
> 	For each header
> 		If header has not already been CTAG-ed
> 			CTAG the header and add definitions to a project level API file
> 		End If
> 	End Loop
> 
> (a) is probably simpler.
> 

Basically, both the steps are necessary. When the user first open the
Project, the TagsManager will load the cache for the project. And then
it goes through every file in the project and determines which one has
been modified since the last scan. It will create a list of filenames to
be updated. Then it scans them one by one with a progress indicator.

After that, file savings will update the individual files, keeping the
TagsManager uptodate.

You can have a look in the ccview module too, to have a general idea how
the progress works with the scanner in non-blocking mode.

> Note that this is in no way a perfect solution. I can think of quite a few 
> drawbacks to this, namely:
> 
> a) Memory consumption - this will be quite high when the user has a large 
> number of open files since we need to maintain a seperate TagsManager object 
> for each file. Of course, we can have a project level TagaManager object like 
> we do now and sacrifice some accuracy for speed and low memory usage.

As, I told you we need only one generic TagsManager. Which will store
the information. Individual files will contact this when they need the
information.

> b) CTAGS has some inherent limitations which we'll have to live with. 
> Firstly, it does not extract the full function/macro definition but just the 
> line containing the definition - it might be a problem for multiline 
> declarations (Using the python program dynamically will be too slow I 
> believe). Also, ctags cannot parse a stream - which is why in the second 
> function, I was writing the pre-parsed file to a temporary file before 
> running ctags on it.

Well, someday, we may even overcome this in a better or faster way. :-)

Good luck and wish you all the best. Keep posting when you need help.

--

Regards,
-Naba

-------------------------------------------------------------
The number of licorice gumballs you get out of a gumball machine
increases in direct proportion to how much you hate licorice.
-------------------------------------------------------------



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