Re: [RFC] Combining of Exuberant Ctags and GNU GLOBAL

[Hideki IWAMOTO]

Hi. Yamaguchi san.

> We can also find the head of <kind name>. It's easy.
> (<tag name> does not include a blanks.)

This is not correct.
At least, C++ parser outputs the tag name including multiple blanks.
(The current implementation of Exuberant Ctags plugin uses
only the last component in ctags tag name as gtags tags name.)

$ find /usr/include/ | xargs ctags -xu --filter --format=1 | egrep 
'^[^[:space:]]+[[:space:]]+[^[:space:][:digit:]][^[:space:]]*[[:space:]]+[^[:space:][:digit:]]'
 | head
operator const char_type*  637 /usr/include/mozilla-1.7.12/string/nsTString.h 
operator const char_type*() const
operator const char*  259 
/usr/include/mozilla-1.7.12/xpcom_obsolete/nsFileSpec.h operator const char*() 
const { return mData ? mData->mString : 0; }
operator const char*  356 
/usr/include/mozilla-1.7.12/xpcom_obsolete/nsFileSpec.h operator const char* () 
const { return GetCString(); }
operator const FSSpec* const  377 
/usr/include/mozilla-1.7.12/xpcom_obsolete/nsFileSpec.h operator const FSSpec* 
const () { return &mSpec; }
operator const FSSpec&  379 
/usr/include/mozilla-1.7.12/xpcom_obsolete/nsFileSpec.h operator const FSSpec& 
() const { return mSpec; }
operator const char*  555 
/usr/include/mozilla-1.7.12/xpcom_obsolete/nsFileSpec.h operator const char* () 
const { return (const char*)mURL; } // deprecated.
operator const char*  597 
/usr/include/mozilla-1.7.12/xpcom_obsolete/nsFileSpec.h operator const char* () 
const { return mPath; }
operator const T&  124 /usr/include/boost/concept_archetype.hpp operator const 
T&() const { return static_object<T>::get(); }
operator const value_type&  420 /usr/include/boost/concept_archetype.hpp 
operator const value_type&() const { return static_object<T>::get(); }
operator unsigned short   42 
/usr/include/boost/date_time/gregorian/greg_year.hpp operator unsigned short() 
const {return value_;}

On Fri, 14 Sep 2012 09:05:10 +0900
"Shigio YAMAGUCHI" <address@hidden> wrote:

> Hi, Iwamoto san,
> > Since Exuberant-Ctags plugin scans a line backward after
> > finding file name, ...
> 
> According to this method, it seems that there is no problem.
> 
> We can find the tail of <kind name> by tracing from <file name>.
> (<line number> does not include a blank.)
> 
>                            v<-----------------
>       <tag name> <kind name>  <line number>  <file name> ...
> 
> We can also find the head of <kind name>. It's easy.
> (<tag name> does not include a blanks.)
> 
>       ---------->v
>       <tag name> <kind name>  <line number>  <file name> ...
> 
> What exists between them is <kind name>.
> 
>       ----------><kind name><-----------------
> 
> Although we cannot deny that there is useless cost, it is
> not so serious. How about discussing about it in the
> optimization phase? It had not determined yet whether we use
> <kind name> or not.
> --
> Shigio YAMAGUCHI <address@hidden>
> PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3