[Lxr-dev] Re: [Lxr-commits] CVS: lxr/lib/LXR Lang.pm,1.25,1.26

[Malcolm B. <ma...@br...>]

Hi,



Jan-Benedict Glaw wrote:

>Please, take Lang.pm and read some further lines. There, we fetch
>a (possible) shell bang and test it against the occurence of "perl".
>Bad.
>
Yep, you're right, this is special-casing for perl.  If anyone fancies 
coding up a patch to do what JBG suggests below then I'll be happy to 
add it.

>Spoken C'ish, there's an array of structs in lxr.conf (sorry,
>I'm not Perl-enabled...) containing language descriptions. This
>includes some possible filename extensions which are almost
>reasonable. Why don't we add a struct member called "interpreters"
>containing a list of possible interpreters, if there's not a match
>for the filename extension.
>
Do you mean that this would be a seperate meta-language called 
'interpreters', or that the perl/bash etc entries would also include 
their interpreter strings?

>Lang.pm does this exceptional for Perl, I'd like to see this behavior
>to be a bit more flexible by scanning over thise things there in
>lxr.conf. There's no need for a perl script to end up in .pl, equally
>there's no need for s shell script to end up in .sh. So why don't we
>generally also test for a shell bang (if there's no extension)?
>
One way to do this of course is simply to extend Lang.pm - it's pretty 
trivial, though not exactly flexible.

I think the best way to do it is to have an 'interpreters' entry in 
lxr.conf that maps between potential #! strings and languages.  Then to 
get the right info, just look the language name back up in the filetype 
mapping.  This avoids having to specify things like the module or 
tabwidth twice, without the overhead of looking at the first line of the 
file if the filename mapping works out.

In fact, I'm so inspired I'll even code it.  How's the for volunteers?

Malcolm