[RFC] New requirement for plug-in parser.

[Shigio YAMAGUCHI]

Hi all,

I would like to adding new requirement for plug-in parser of GLOBAL
to make external sort filter unnecessary.

Now, gtags(1) and global(1) use external POSIX sort command when
plug-in parser is used. However, it is annoying to keep maintaining
the mechanism only for plug-in parser. Instead, we should clarify
the requirement for plug-in parser, I think.
How about followings?

------------------------------------------------------------------------
[Requirement of plug-in parser (=the program)]

1. Plug-in parser must process the files in the order they are given
   in the argument.

        $ ctags -xu a.c b.c        <= order: a.c -> b.c
                    ~~~~~~~
        main          25 a.c  main(int argc, char *argv[])
        sub1          10 b.c  sub1() {
                          ^
                          |
                         *** order: a.c -> b.c

2. In a file, plug-in parser must write tags out as they are encounterd.

        $ ctags -xu a.c
        main          25 a.c  main(int argc, char *argv[])
        func          45 a.c  func() {
                       ^
                       |
                      *** order: line 25 -> line 45

(end of requirement)
------------------------------------------------------------------------

If the above-mentioned requirement is filled, external sort filter
becomes unnecessary. I think that the requirement is not a big
restriction, because:
o since any special processing is unnecessary, the load of work to make
  a new parser is light.
o exuberant ctags which is a typical tag command substantially fills
  this requirement.

I asked exuberant ctags mailing list the specification of the -u option
of ctags. Darren Hiebert, the author of exuberant ctags answered like
this:

Darren Hiebert wrote:
>The intent of the option is simply to be unsorted.
>
>However, the implementation is to process the files in the order
>they are parsed, with lines processed in the order they appear,
>writing tags out as they are encountered. I don't see any reason
>why that might change, as it would take deliberate work to do it
>differently.
>
>Therefore, you should be able to rely on the ordering as you presented it.
>That's about as good a guarantee as I can give.
>
>On Mon, 30 Jan 2006, Shigio YAMAGUCHI wrote:
>
>> It seems that the output of ctags with the -u (--sort=no) option
>> is written in order as appearance of files and tags.
>> Is the following things guaranteed?
>>
>> 1. The output is written in order as being specified by the argument.
>>
>> % ctags -xu a.c b.c        <= order: a.c -> b.c
>>            ~~~~~~~
>> main          25 a.c  main(int argc, char *argv[])
>> sub1          10 b.c  sub1() {
>>                   ^
>>                   |
>>                  *** order: a.c -> b.c
>>
>>
>> 2. In a file, written in order as appearance of tags.
>>
>> % ctags -xu a.c
>> main          25 a.c  main(int argc, char *argv[])
>> func          45 a.c  func() {
>>                ^
>>                |
>>               *** order: line 25 -> line 45
>>
>> Or, is it meant only not to be sorted?

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