RE: GNU Global Parsing Suffixless Files Patch

[Cooper, Anthony]

SECURITY CLASSIFICATION: OFFICIAL 


Oops sorry just clicked on reply and not reply all...

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Shigio YAMAGUCHI
Sent: 29 September 2016 13:14
To: Cooper, Anthony
Subject: Re: GNU Global Parsing Suffixless Files Patch

Hi Tony,
It seems that this mail is not posted to GLOBAL bug mailing list.
If possible, would you please post this mail to the address@hidden
I'd like to always argue about GLOBAL at the public place.
Thank you in advance.

Regards,
Shigio


2016-09-29 19:23 GMT+09:00 Cooper, Anthony <address@hidden>:


        SECURITY CLASSIFICATION: OFFICIAL
        
        
        I still feel the regex approach offers more flexibility. How about we 
adopt the () approach you mentioned below such that:
        
                gtags --language-force=cpp\:project/include
        
        Is a real path as you suggest and:
        
                gtags --language-force=cpp\:([Ii]nclude)
        
        is a regex pattern contained in (). Since we are doing one entry per 
option we don't even need to worry about escaping () in the regex as we simply 
strip off the outer ones once we have worked out that it's a pattern. This 
would also be consistent with ctags.
        
        I'll see what I can come up with... Do you want case 2 implemented or 
leave that as a separate additional feature?
        
        Regards,
        
        Tony.
        
        -----Original Message-----
        From: address@hidden [mailto:address@hidden On Behalf Of Shigio 
YAMAGUCHI
        
        Sent: 28 September 2016 02:51
        To: Cooper, Anthony
        Cc: address@hidden
        Subject: Re: GNU Global Parsing Suffixless Files Patch
        
        > - 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 <address@hidden 
<mailto:address@hidden> >:
        
        
                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 
<mailto:address@hidden>  <mailto:address@hidden <mailto: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>  
<https://lists.gnu.org/mailman/listinfo/bug-global 
<https://lists.gnu.org/mailman/listinfo/bug-global> >  
<https://lists.gnu.org/mailman/listinfo/bug-global 
<https://lists.gnu.org/mailman/listinfo/bug-global>  
<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 
______________________________________________________________________
        
        
        
        
        
        
        --
        
        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 
______________________________________________________________________
        
        




-- 

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 
______________________________________________________________________