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: i.tama...@gmail.com [mailto:i.tama...@gmail.com] On Behalf Of Shigio
YAMAGUCHI
Sent: 23 September 2016 02:20
To: Cooper, Anthony
Cc: bug-global@gnu.org
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 <anthony.coo...@gchq.gsi.gov.uk>:
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 postmas...@gchq.gsi.gov.uk.
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
info...@gchq.gsi.gov.uk
****************************************************************************
_______________________________________________
Bug-global mailing list
Bug-global@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-global
<https://lists.gnu.org/mailman/listinfo/bug-global>
--
Shigio YAMAGUCHI <shi...@gnu.org>
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
______________________________________________________________________
_______________________________________________
Bug-global mailing list
Bug-global@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-global
