> 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 <[email protected]>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
_______________________________________________
Bug-global mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-global
