Potential gotcha in types: How do we handle the R language?

[petdance]

Ben (midfield@gmail.com) emailed me about adding support for R in ack. I said I wasn't going to add anything to ack 1.x, but this sort of type handling is something we need to be aware of going forward. We already have C as --cc, but what will we do with R? D?

hello --

thanks for the great product.

1) i think R is being used enough to deserve a type in ack.  i think
.R is a common extension for it.

2) in a related note, i had

--type-set=R=.R

in my .ackrc but it didn't work.  i looked at the source and
discovered that this is because ack down-cases the file extensions
before comparing with the known extensions.  hence any extension
that is not all lowercase will never match.  changing it to

--type-set=R=.r

fixed it.  this is a little confusing for people who are used to
upper case extensions (as with R.)  as such i propose that ack
automatically internally down-case any extension specified by a
--type-set or --type-add, to prevent confusing users.

just my 2 cents.

best,
ben

[midfield]

it doesn't seem like problem long as you don't want to distinguish between upper / lower case. having both .R and .r be R files is ok. just as a user-interface issue i think you should downcase extensions before putting them into the $types map, so people don't get confused (like i did.)

however, some people seem to want case-sensitive extensions:

beyondgrep/ack1#193

[petdance]

If you create a single-character type, you're going to have to use it via --type=R, or else make the type be "rr" like we do with "cc".

[hoelzro]

I added this as --rr.