RE: GNU Global Parsing Suffixless Files Patch

[Cooper, Anthony]

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


        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
        https://lists.gnu.org/mailman/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 
______________________________________________________________________