Hi, Iwamoto san,
> If new format is based on format1, it is impossible to implement
> `Support of tag type. (like Exuberant Ctags)' which is listed in plans.html.
> I think that the new format should be based on format2.
You are right.
How about using a franker option like '--gtags'? This option
adds a type string at the head of each record like follows:
$ ctags -x --format=1 --gtags
D func 5 test.c func() {
$ ctags -x --format=2 --gtags
D func function 5 test.c func() {
We should be able to consider the type string does not belong
to the format.
> I think that the reason why exuberant-ctags plugin uses format1 is
> blanks may be included in tagname and tagkind.
> If an option to escape blank characters in tagname and tagkind is added to
> Exuberant Ctags,
> the border of tagname and tagkind in fomrat2 output becomes recognizable.
By using '--format=1 --gtags', the present problem is avoidable.
> The reference tag support is also implementable by using special tagkind
> such as "other\ than\ definition" in format2 output.
> The author of Exuberant Ctags may prefer this method to adding new format
> and may not be so.
Isn't it more desirable to separate the tagkind (based on language)
and the type string (based on GLOBAL's implementation)? But it should be
chosen by the developers of Exuberant Ctags. I would like to show this
as an option which can be choose.
Thank you for comment.
Shigio
--
Shigio YAMAGUCHI <[email protected]>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
_______________________________________________
Bug-global mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-global
