[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Function palyer plugin parser

From: Shigio YAMAGUCHI
Subject: Re: [PATCH] Function palyer plugin parser
Date: Wed, 17 Feb 2010 15:05:47 +0900

> 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.


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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]