Re: Feature request: file list

[Marcus Harnisch]

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 <address@hidden> 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 <address@hidden>:

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 <address@hidden>

PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3