Hi Shigio

Sure, GTAGS_COMMANDLINE would be fine, too. This could be scanned by the
hook script with getopts(1) in case access to individual elements is needed.
In my case the application could be to determine the file name that has
been specified with -f and use that to dump the output generated by the
hook script.

Thanks,
Marcus


On Mon, Oct 17, 2016 at 3:35 AM, Shigio YAMAGUCHI <shi...@gnu.org> wrote:

> Hi,
> > However, I am not entirely happy from a usability perspective.
> > In particular it would be helpful to have the hook know about all active
> > command line options, even those passed in by GTAGS_OPTIONS (e.g. for
> > determining the -f parameter). This doesn't seem possible at the moment,
> > as the hook script is executed rather early, before options processing
> > has started. Perhaps GTAGS_OPTIONS should be set to the effective list
> > of options by gtags before calling the hook.
>
> How about storing effective command line to new environment variable
> GTAGS_COMMANDLINE?
>
> [gtags.conf]
> :GTAGS_OPTIONS=-c:\                     -- default option
> :gtags_hook=./gen.sh:\
>
> [./gen.sh]                              -- hook script
> #!/bin/sh
> echo $GTAGS_COMMANDLINE                 -- print effective command line
>
> [command line]
> $ gtags -O                              -- command line option
> gtags -c -O                             -- effective command line (-c + -O)
> $ _
>
> The values in GTAGS_COMMANDLINE are separated with a space. So, I would
> like to
> encode real spaces in them with '%20'.
>
> e.g.
> File name includes a blank.
> 'App file' -> App%20file
>
> You can decode it like this:
>
> $ echo 'App%20file' | sed 's/%20/ /g'
>
> What do you think?
>
> > Another, losely related, issue popped up in testing this: When I make an
> effort
> > to provide a list of files to scan (rather than gtags searching the
> directory),
> > then a user could expect that this list not further mangled with. While
> the skip
> > interaction is documented under ‘skip’, I think this asell as the
> --accept-dotfiles
> > option deserve to be mentioned in the ‘gtags.files’ description.
>
> Certainly the relationship between them has not been described in the
> document.
> I will add such a document. Please wait a little.
>
> Regards,
> Shigio
>
>
> 2016-10-15 6:38 GMT+09:00 Marcus Harnisch <marcus.harni...@verilab.com>:
>
>> Hi Shigio
>>
>> I played with the gtags_hook and managed to generate a file list with the
>> help of rsync(1), so I can take full advantage of the powerful syntax of
>> its --exclude-from option. This works quite well as a proof-of concept
>> generic hook script, that could be installed systemwide.
>> However, I am not entirely happy from a usability perspective. In
>> particular it would be helpful to have the hook know about all active
>> command line options, even those passed in by GTAGS_OPTIONS (e.g. for
>> determining the -f parameter). This doesn't seem possible at the moment, as
>> the hook script is executed rather early, before options processing has
>> started. Perhaps GTAGS_OPTIONS should be set to the effective list of
>> options by gtags before calling the hook.
>>
>> Another, losely related, issue popped up in testing this: When I make an
>> effort to provide a list of files to scan (rather than gtags searching the
>> directory), then a user could expect that this list not further mangled
>> with. While the skip interaction is documented under ‘skip’, I think this
>> as well as the --accept-dotfiles option deserve to be mentioned in the
>> ‘gtags.files’ description.
>>
>> Many thanks
>> Marcus
>>
>
>
>
> --
> Shigio YAMAGUCHI <shi...@gnu.org>
> PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3
>
_______________________________________________
Bug-global mailing list
Bug-global@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-global

Reply via email to