> True, I was thinking of when it's integrated as a part of an editor/IDE and gets > called directly, like emacs, on writing a file and browsing multiple projects > with there own global databases. Again you can add something to the path at the > start with your shell script... Anyway in reference to:
OK. How about adding a hook like this? [gtags.conf] :gtags-hook=find ..... > cppfiles: When 'gtags-hook' is used, gtags(1) executes the hook before its job. Of course, you can use shell script instead of find(1). This is similar to emacs's 'add-hook'. Regards, Shigio 2016-10-07 3:28 GMT+09:00 Cooper, Anthony <[email protected]>: > SECURITY CLASSIFICATION: OFFICIAL > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Shigio YAMAGUCHI > > Sent: 06 October 2016 07:10 > > To: Cooper, Anthony > > Cc: [email protected] > > Subject: Re: Tony.RE: GNU Global Parsing Suffixless Files Patch > > > > > At one stage I thought of extending the gtags file format to include > > > an optional language override, it's similar to your file list idea... > > > However as I used global more I started to shy away from that as > > > it's high maintenance and would break automatic recursive update on > > > file > > addition. > > > > > > For example: If you're working on a project that has non-standard > > > file naming conventions and/or has particular type types in odd > > > places (like my texi/inc example) then if you used a file list/type > > > approach you'd need to update that each time you added another > > > suffixless header > > file. > > > > The can not be automated is a misunderstanding. You can automate it > > just to write the following script and use instead of 'global -u'. > > > > [global-u.sh] > > +----------------------------------------------------------- > ------ > > |#!/bin/sh > > |root=`global -pr` && cd $root # Move to the > project root > > |if [ $? = 0 ]; then > > | find ..... > cppfiles # Make cppfiles > > | gtags -i --force-language=cpp:cppfiles > > |fi > > > > +----------------------------------------------------------------- > > > > True, I was thinking of when it's integrated as a part of an editor/IDE > and gets called directly, like emacs, on writing a file and browsing > multiple projects with there own global databases. Again you can add > something to the path at the start with your shell script... Anyway in > reference to: > 1 - Existing langmap style extension list e.g. `.c.h'. > 2 - File only glob pattern e.g. `([Mm]akefile)'. > 3 - A mixture of the above two e.g. `.c.h([Mm]akefile)(*.inc)' > 4 - A dumb path substring match (possibly with the caveat that it > must start with ./ or / to distinguish it from the above?) e.g. '/include/'. > 5 - A bare name of a file containing a list of filenames e.g. > `cppfiles'? > What were you thinking of supporting in --force-language then? > > > It was merged to Universal Ctags. But there is no parser which use the > > mechanism yet. > > (See makeSimpleRefTag in main/parse.c) > > Are ok... Mind you they haven't had a release for a long time as far as I > can tell. I thought I had got an old site at first. > > Regards, > > Tony. > <Snip> > > ************************************************************ > **************** > Communications with GCHQ may be monitored and/or recorded > for system efficiency and other lawful purposes. Any views or > opinions expressed in this e-mail do not necessarily reflect GCHQ > policy. This email, and any attachments, is intended for the > attention of the addressee(s) only. Its unauthorised use, > disclosure, storage or copying is not permitted. If you are not the > intended recipient, please notify [email protected]. > > This information is exempt from disclosure under the Freedom of > Information Act 2000 and may be subject to exemption under > other UK information legislation. Refer disclosure requests to > GCHQ on 01242 221491 ext 30306 (non-secure) or email > [email protected] > > ************************************************************ > **************** > > -- 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
