bug-global
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Alternative filename for local configuration.


From: Shigio YAMAGUCHI
Subject: Re: [PATCH] Alternative filename for local configuration.
Date: Wed, 8 Mar 2017 07:37:26 +0900

> I'm aware of XDG recommendations, but it was not my point.
> I was just thinking of checking for alternative name (like DOS_GTAGSRC
> is checked if GTAGSRC is not found).
> The purpose I see a way to hide (using dot-prefix) global configuration
> from clients who don't use and don't care about global.
> That's it.

Sorry, I cannot understand what you are saying.
Would you please explain it by example?

> The problem is, I have to provide whole configuration per project (directory),
> so effectively I would copy SYSCONF to project directory and make that change
> (add .IPP to the cpp parser).
> $ cp /etc/gtags.conf MYPROJ/ (and edit local copy)
>
> Instead I would like to append that entry; using some imaginary termcap notation:
> builtin-parser:langmap:cpp:+.IPP

Is it insufficient with 'tc' variable?
(man gtags.conf)

Regards,
Shigio


2017-03-07 23:53 GMT+09:00 Jacek Migacz <address@hidden>:
Hi.

I'm aware of XDG recommendations, but it was not my point.
I was just thinking of checking for alternative name (like DOS_GTAGSRC is checked if GTAGSRC is not found).
The purpose I see a way to hide (using dot-prefix) global configuration from clients who don't use and don't care about global.
That's it.

----

However there is another story. You have listed 1-8 strategies of providing global configuration.
I would divide it into 3 categories:
  • System configuration: SYSCONF
  • User configuration: USERCONF
    Directory configuration: DIRCONF
I would have:
  • DIRCONF: Inherits and shadows USERCONF (if USERCONF is defined, if not ihnerits and shadows SYSCONF if SYSCONF is defined)
  • USERCONF: Inherits and shadows SYSCONF (if SYSCONF is defined)
For example:
There is some C++ project that is using some non-standard files extensions like .IPP to indicate interface headers.
For this particular project I would have to define GTAGSCONF as follows:
...
builtin-parser:\
    :langmap=c\:.c.h,yacc\:.y,asm\
:.s.S,java\:.java,cpp\:.c++.cc.hh.cpp.cxx.hxx.hpp.C.H.IPP,php\:.php.php3.phtml:
...

The problem is, I have to provide whole configuration per project (directory), so effectively I would copy SYSCONF to project directory and make that change (add .IPP to the cpp parser).
$ cp /etc/gtags.conf MYPROJ/ (and edit local copy)

Instead I would like to append that entry; using some imaginary termcap notation:
builtin-parser:langmap:cpp:+.IPP


Or let's say I'm working on several projects and it's common for my organization to have BUILD directory in project root path (like MYPROJ/BUILD) and one of these projects is using special extensions for C source files to indicate code standard, like .c98 and .c99.
For every single project I would have to copy GTAGSCONF to its root patch.
I would have to change the skip entry in every configuration to ignore BUILD directory as follows:
...
common:\
    :skip=HTML/,HTML.pub/,tags,TAGS,ID,y.tab.c,y.tab.h,gtags.files,cscope.files,cscope.out,cscope.po.out,cscope.in.out,SCCS/,RCS/,CVS/,CVSROOT/,{arch}/,autom4te.cache/,*.orig,*.rej,*.bak,*~,#*#,*.swp,*.tmp,*_flymake.*,*_flymake,BUILD/:
...

And I would have edit langmap for buildin-parser only for one project with non-standard extensions (.c89 and .c99) as follows:
...
builtin-parser:\
    :langmap=c\:.c.h.c89.c99,yacc\:.y,asm\:.s.S,java\:.java,cpp\:.c++.cc.hh.cpp.cxx.hxx.hpp.C.H,php\:.php.php3.phtml:
...


Instead, I'd like to append BUILD/ to skip list for my user, by editing USERCONF using some imaginary termcap notation:
common:skip:+BUILD/
And I'd like to append non-standard suffixes to project's DIRCONF only using some imaginary termcap notation:
builtin-parser:langmap:c:+.c89.c99

This way my "single USERCONF" and "single DIRCONF" would contain few lines of information instead of hard copy of whole GTAGSCONF.

What do you think about that Shigio-san?



Regards,
Jacek Migacz


2017-03-07 0:32 GMT+01:00 Shigio YAMAGUCHI <address@hidden>:
Hi,
> would you consider checking for alternative local
> configuration filename: ".gtags.conf"?

OK. I also dislike a name '.globalrc'.
But it may be also undesirable to create a new dot file.
The XDG guidelines recommend that applications store their configuration
in $XDG_CONFIG_HOME/<app>. How about following this?

XDG Base Directory Specification

According to this specification, the configuration priority of GLOBAL seems to
become like follows:

       (1) --gtagsconf file

       (2) $GTAGSCONF

       (3) [project root]/gtags.conf

       (4) $HOME/.globalrc

       (5) $XDG_CONFIG_HOME/gtags/gtags.conf          <= New

       (6) $HOME/.config/gtags/gtags.conf             <= New

       (7) /etc/gtags.conf

       (8) [sysconfdir]/gtags.conf

What do you think?

Regards,
Shigio


2017-03-07 2:07 GMT+09:00 Jacek Migacz <address@hidden>:
Hi Shiyao-san,

would you consider checking for alternative local configuration filename: ".gtags.conf"?

Regards,
--
Jacek Migacz

_______________________________________________
Bug-global mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-global




--
Shigio YAMAGUCHI <address@hidden>
PGP fingerprint: 
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB (Currently in use)
D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3 (Used until 2017/2)



--
Jacek Migacz



--
Shigio YAMAGUCHI <address@hidden>
PGP fingerprint: 
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB (Currently in use)
D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3 (Used until 2017/2)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]