Thread: [Lxr-dev] Re: [Lxr-commits] CVS: lxr/lib/LXR Lang.pm,1.25,1.26
Brought to you by:
ajlittoz
From: Malcolm B. <ma...@br...> - 2002-01-23 14:58:28
|
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 |
From: Jan-Benedict G. <jb...@lu...> - 2002-01-23 15:50:35
|
On Wed, 2002-01-23 23:22:47 +0900, Malcolm Box <ma...@br...> wrote in message <3C4...@br...>: Hi, > Jan-Benedict Glaw wrote: > >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? I would do the later one. I think it's quite easier to do it that way around... > >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 That's fine with me, too:-) > 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? Oh yes, please, do it. I like it, but I can't do it. I've looked at Perl several times, I always failed. My braindumps look more like C... MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ |