> Yes that sounds a lot nicer. Also if one gave a relative path to the script
> then this could be taken from where the GPATH database files are found.
> Then that would mean you could have a config being used by a number of
> different projects and also would work when you do a global -u as that
> needs to find the databases from anywhere in the project and it might
> as well use that same location for the hook script. Thus a generic config
> along with specific hook scripts and databases per project.
You are right.
> In reference to:
> 1 - Existing langmap style extension list e.g. `.c.h'.
> 2 - File only glob pattern e.g. `([Mm]akefile)'.
> 3 - A mixture of the above two e.g. `.c.h([Mm]akefile)(*.inc)'
> 4 - A dumb path substring match (possibly with the caveat that it must
> start with ./ or / to distinguish it from the above?) e.g. '/include/'.
> 5 - A bare name of a file containing a list of filenames e.g. `cppfiles'?
> What were you thinking of supporting in --force-language then?
I think 5 is enough.
The file list is suitable for dealing with those with no rules.
We can write rule-based descriptions (1, 2, and 3) to the langmap.
> By the way I'm going away on a source code analysis and comprehension workshop
> for maybe up to two weeks and so my access to my business email may well be
> limited, so please don't think I'm ignoring you (although you'll probably be
> glad of the peace and quiet! :-)).
OK. Thank you for the constructive discussion!
Regards,
Shigio