|
| From: | Shigio YAMAGUCHI |
| Subject: | Re: GNU Global Parsing Suffixless Files Patch |
| Date: | Wed, 28 Sep 2016 10:51:10 +0900 |
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.
https://lists.gnu.org/mailman/-----Original Message-----
From: address@hidden [mailto:address@hidden] On Behalf Of Shigio YAMAGUCHI
Sent: 23 September 2016 02:20
To: Cooper, Anthony
Cc: address@hidden
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 <address@hiddenuk >:
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 address@hidden.
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
address@hidden
************************************************************ ****************
_______________________________________________
Bug-global mailing list
address@hidden
listinfo/bug-global <https://lists.gnu.org/mailman/listinfo/bug-global >
--
Shigio YAMAGUCHI <address@hidden>
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 ____________________________________________________________ __________
| [Prev in Thread] | Current Thread | [Next in Thread] |