> - You refer to `C++' in your example, would it not be better to use `cpp'?
You are right.
> - Also the path matching. Wouldn't having this as a regex give the best
of both worlds?
> If you wanted to match a file you could end in a $ as in 'boot-system$'
or a directory
> component '/include/'. Otherwise you might find yourself trying to
stipulate that a file
> `run-command' is Perl but also inadvertently mark everything under a
`run-command'
> directory in the same project as Perl as well? I know it's a rather
contrived example,
> but it could happen...
How about using a real path for the option?
gtags --language-force=cpp\:project/include
===============
^
This is not a pattern but a real path.
The user should know whether it is a directory or not. If the file or
directory is not
found, then gtags will display the following warning message:
$ gtags -w --language-force=cpp\:project/include
gtags: Warning: 'project/include' not found.
> If you're happy with the two points above would you like me to make a new
patch or
> would you rather do it yourself?
If you hope it and you debug a program, I welcome that.
But you don't have to force yourself. It's a big help for us only by your
participating
in this argument.
I will put this issue on the TODO list.
Regards,
Shigio
2016-09-27 0:20 GMT+09:00 Cooper, Anthony <[email protected]>:
> SECURITY CLASSIFICATION: OFFICIAL
>
>
> Hi Shihio,
>
> Thank you for replying.
>
> The intention of my patch was to really address case 1. I did look
> at implementing something akin to scenario 2, but felt that was of less
> benefit (I admit a purely selfish decision! :-)).
>
> I tried to think of the times when one would most likely want to
> use this feature and apart from the C++ STL case, probably the most likely
> case is when a project is using scripting languages in suffixless
> executable files; thus possibly leading to quite a large mixture of
> language exceptions in a project. Hence I opted for an approach that was
> good at handling potentially very long lists.
>
> However looking at your idea it does have the value of consistency
> with ctags, offers greater flexibility and still meets my `put it in a
> config file' requirement, so yes your idea does look better.
>
> I did notice a couple of things though:
> - You refer to `C++' in your example, would it not be better to use `cpp'?
> As this is consistent with values used in the config file and can be
> validated against the list of supported languages as I do for
> suffixless_lamgmap.
> - Also the path matching. Wouldn't having this as a regex give the best of
> both worlds? If you wanted to match a file you could end in a $ as in
> 'boot-system$' or a directory component '/include/'. Otherwise you might
> find yourself trying to stipulate that a file `run-command' is Perl but
> also inadvertently mark everything under a `run-command' directory in the
> same project as Perl as well? I know it's a rather contrived example, but
> it could happen...
>
> As for case 2, that's fine, although I'm not sure where one would
> use it though unless Global copes with Makefile, COPYING, CHANGELOG etc
> type files (which it may do via ctags for all I know :-)).
>
> BTW many thanks for Global, it's _such_ a useful tool :-).
>
> If you're happy with the two points above would you like me to
> make a new patch or would you rather do it yourself?
>
> Yours sincerely,
>
> Tony.
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Shigio YAMAGUCHI
> Sent: 23 September 2016 02:20
> To: Cooper, Anthony
> Cc: [email protected]
> Subject: Re: GNU Global Parsing Suffixless Files Patch
>
> Hi,
> Thank you for the patch and suggestion.
>
> I'd like to separate this issue in two cases.
>
> case1: Files under the specific directory like /usr/include/c++/4.2.1
>
> Should that be written on the configuration file as a rule?
> In fact shouldn't that be written on the command line of gtags?
>
> $ gtags --language-force=C++:include --language-force=C++:project/include
>
> --language-force=<language>:<file or directory> If it is a file, it is
> considered <language> source file.
> If it is a directory, all files under it are considered <language> source
> file.
>
> If needed, you can make this option default:
>
> # Making project base gtags.conf
> $ echo 'default: GTAGS_OPTIONS=--language-force=C++\:include \
> --language-force=C++\:project/include' >gtags.conf
> $ gtags # gtags is executed as 'gtags --language-force=...'
>
> case2: Files which have a specific name like 'Makefile'
>
> Since it is considered as a rule, it should be written on the
> configuration file, I think. For example, 'Makefile' should be written like:
>
> [gtags.conf]
> # A pattern matches only to files.
> :langmap=cpp\:([Mm]akefile).mk.mak:
>
> '(<pattern>)' is a syntax of ctags(1)'s langmap. Since I borrowed 'langmap'
> from ctags(1), I would like to copy that again.
>
> What do you think?
>
> Regards,
> Shigio
>
>
> 2016-09-21 23:52 GMT+09:00 Cooper, Anthony <[email protected]
> >:
>
>
> SECURITY CLASSIFICATION: OFFICIAL
>
>
> Hi all,
>
> I've included a patch that allows global to parse and
> index files without an extension (typically C++ header files, e.g.
> /usr/include/c++/4.8/algorithm and many more). This works by having a set
> of rules whereby a user can specify path regexs and the corresponding
> source file types for files without a suffix. This is done by specifying a
> rule, similar to langmap, like this:
>
> default: \
> :GTAGSFORCECPP: \
> :suffixless_langmap=[iI]nclude\:cpp,project/include\:cpp:
>
> This can be specified on multiple lines like langmap. Also
> the regex can be used to match any part of a path, including the filename
> if necessary.
>
> I know you want patches that apply to the head of your
> main branch but unfortunately our organisation's firewall prevents me from
> connecting to your CVS server, so they are based on your latest release
> (6.5.4).
>
> Regards,
>
> Tony Cooper.
>
> ************************************************************
> ****************
> 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]
>
> ************************************************************
> ****************
>
>
> _______________________________________________
> Bug-global mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/bug-global <
> https://lists.gnu.org/mailman/listinfo/bug-global>
>
>
>
>
>
>
> --
>
> Shigio YAMAGUCHI <[email protected]>
> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>
>
--
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
