bug-global
[Top][All Lists]
Advanced

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

Re: [RFC] A project basis configuration mechanism


From: Leo Liu
Subject: Re: [RFC] A project basis configuration mechanism
Date: Mon, 07 Apr 2014 09:14:56 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (CentOS 6.5)

On 2014-04-04 14:03 +0800, Shigio YAMAGUCHI wrote:
> It is too vague for discussing. Would you please explain it for example?
> In what case is it useful?

Sorry for my delay in reply.

For example, I want to just specify:

default:\
        :tc=native:tc=drupal:

as my project's gtags.conf file i.e. without copying the whole
gtags.conf over. My $HOME/.globalrc or system-wide gtags.conf will
already contain the entries for label `native' and `drupal'. my project
should inherit those settings.

>> > 1.2 gtags.label
> ...
>>
>> But we should keep the interface as simple as possible. Introducing
>> another file is another complication. For example in my drupal project's
>> gtags.conf I have:
>>
>> default:\
>>         :tc=native:tc=drupal:
>>
>> So I already have the ability to pick and compose any label. I think we
>> should also get rid of the .notfunction file and move this feature to
>> gtags.conf.
>
> Since gtags.conf has a function to hold two or more configurations in
> one file, a configuration is specified by both file name and label name.
> If we offer project basis gtags.conf, we should also offer project basis
> label, I think.

We don't need it. We either just pick the first label in the project's
gtags.conf or (by convention) the 'default' label.

The `.notfunction' should also be obsolete and move into gtags.conf.

The `gtags.files' can be replaced by providing something similar to the
skip list where we can specify subdirectories or by extensions for
example, only index *.m files etc.

I think with these features users only need to worry about one single
file gtags.conf. We can even provide a dedicated man page for it to help
new comers get started.

> Use of gtags.label is completely upward compatible. If unnecessary for you,
> you need not use it. It is completely transparent also for the systems
> which use GLOBAL. So, it does not bring any new complication.
>
>> BTW, the configuration uses TERMCAP style. Could you point me to its
>> official specification?
>
> About file format, it should be same as termcap.
> About environment variables, please replace as follows, respectively.
>
>         TERMCAP -> GTAGSCONF
>         TERM -> GTAGSLABEL
>
> About the individual variables, it is not fully documented.

HTH,
Leo




reply via email to

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