Re: [RFC] A project basis configuration mechanism

[Leo Liu]

On 2014-04-07 12:50 +0800, Shigio YAMAGUCHI wrote:
> You mean two or more configuration files are effective simultaneously?
> If so, it is not upward compatible. It confuses the present users.

Maybe some area of the tool can break compatibility if the alternative
saves users time and effort to configure new projects. The possibility
of having one or two lines in a project's gtags.conf to make it fully
functional with gtags/global is a great benefit.

> Isn't this enough?
>
> $ cp $HOME/.globalrc gtags.conf
> $ vi gtags.conf
>
>     or

That's precisely what I have been doing. But it has at least three
downsides: a) not easy to know what has changed; b) a 23k file to each
project c) those hardcoded paths in the file may bite you at some point.

> $ echo myproj >gtags.label
>
> [$HOME/.globalrc]
> +---------------------------------
> |myproj:\
> | :tc=native:tc=drupal:
>
> Incompatible changes are difficult for users to accept.
> How about thinking it after introduction of project basis gtags.conf?

Sure but there is no incompatibility here. Project-based configuration
is uncommon as far as global is concerned. Or people will run into
similar difficulties i.e. trying to manage a set of environment
variables for each project.

>> >> > 1.2 gtags.label
>> > ...
>> > 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.
>
> I don't understand what you are saying. Which meaning is it?
>
> o We should stop support of GTAGSLABEL.
> o We should ignore GTAGSLABEL only when project basis gtags.conf is used.

I mean there is no need to add another file just to specify the label to
use. We can automatically pick the first label or pick the 'default'
one.

GTAGSLABEL can continue to exist and may take precedence over
aforementioned scheme.

>> The `.notfunction' should also be obsolete and move into gtags.conf.
>
> Why is it?
>
>> 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.
>
> The 'gtags.files' is the same way as 'cscope.files' of cscope command.
> Since it is familiar for many users, they can utilize their own know-how.
> It is a gloomy thing to study about different specification method
> for every tools.

No need to unplug the support immediately.

>> 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.
>
> It is reverse rather. Those who need only 'gtags.files' need not know about
> 'gtags.conf'.

I am not sure. For example in some other project configuration one might
have something like:

  SOURCE_DIRECOTRES=src/, lib/, lib_src/

How difficult to learn to use it? I find gtags.files difficult to use
and maintain. But we don't need to remove it. The two ways can co-exist.

Thanks for taking my comments,
Leo