>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.
It is a matter of degree. Also in the example shown below, being added
is one line or two lines. It does not require multi-file. The difference
is whether there is any copying or not.
$ cp $HOME/.globalrc gtags.conf
$ vi gtags.conf
Users cannot decide whether 'inheritance over multi-file' is necessary
or not without experience of project-based gtags.conf using single-file.
I hope a gradual change.
>> 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;
How about writing so that it may be known? For example,
[$HOME/.globalrc]
+---------------------------------
|default:\
| :tc=native:tc=common:
|
copy and rewrite
|
v
[<project>/gtags.conf]
+---------------------------------
|default:\
| :tc=myproj:\ <= insert a label
| :tc=native:tc=common:
|myproj:\
| :...:... <= individual specifications
>b) a 23k file to each project
Considering today's computer resources, it is no problem, I believe.
Otherwise, GLOBAL cannot exist. :)
>c) those hardcoded paths in the file may bite you at some point.
Sorry, I cannot understand it.
>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.
Does not '$HOME/.globalrc' inherit from /etc/gtags.conf?
>>> >> > 1.2 gtags.label
...
>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.
Without using a file, how is a label name for each project specified?
>> 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.
It is not such meaning; there is no reason for finishing it.
>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.
Nobody does not write a file list by hand; he does almost all work using
find(1). It has very rich options for selecting paths. Even if we offer
a poor function with a original syntax, nobody will use it. Since users
have much know-how about the command, we don't need to interfere with them,I think.