Re: [PATCH] Function palyer plugin parser

[Shigio YAMAGUCHI]

> I thought only about mixed use of built-in parser and plugin parser. 

I understood why there is no mapping about c, c++, php and
java in the 'plugin-example' entry in gtags.conf.  However,
the mixed use might be too advanced usage as an example.

I thought intuitively that both of the following two examples
put roughly the same result in a C project, but they didn't.

        % setenv GTAGSLABEL ctags-exuberant
        % gtags

        % setenv GTAGSLABEL plugin-example
        % gtags

(1) the former loads the command layer plug-in parser
(exuberant-ctags), but the latter loads the default built-in
C parser.

I changed the latter by adding new entry for C language like
follows to load the function layer plug-in parser.

        :gtags_parser=c\:/usr/local/lib/gtags/exuberant-ctags.la:\

After that, (2) the former makes only GTAGS and GPATH, but
the latter makes GTAGS, GPATH, GRTAGS and GSYMS. The GRTAGS and
GSYMS in the latter are empty.

[Suggestion]

1. How about writing complete mapping including 'langmap' in the the
   'plugin-example' entry not to load the built-in parser?
   There must be users who want to use ctags-exuberant's C parser
   instead of the built-in C parser. Those who hope mixed usage
   can change it according to his purpose.

2. How about not making empty GRTAGS and GSYMS?
   Seeing empty GRTAGS, some users might think "Good. The -r option
   is available!".  Most users cannot decide whether it is empty
   or not.

What do you think?
--
Shigio YAMAGUCHI <address@hidden>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3