Neil Hodgson wrote:
Since I currently have to work on code in multiple languages stored in files without extensions I've been annoyed by them not being styled by default so am looking at adding some detection of language from the initial #! line that is favoured by Unix users. This would work only when there was no extension, and would use the same override mechanism used by the Language menu. The plan is after the file is opened:if first line starts with "#!": for each word in line: if properties["shbang." + word]: use that property value as the override file extension So with properties: shbang.python=py shbang.ruby=rb Then files that start with, for example "#!/usr/bin/env python" or "#!/usr/bin/ruby" would be treated as Python or Ruby respectively. This is open to some confusion if any languages are called usr, bin, env, or similar. The precedence is arguable with the possibility of files with known extensions overridden by #! but this seems safest. The "shbang." properties can be placed in each .properties file so there is no need for a central property collecting them together as there is for menu.language. The name "shbang" is a little too cute. Since this occurs after reading some of the file contents, it will result in processing the properties twice.
At first blush (and after looking at the other replies so far), it would seem tough to create any single simple algorithm for doing auto detection of language... that makes everyone happy. ;)
How about a global prop like "enable.auto.language" with "no", "if no match on extension", and "always (allow override of extension)" values... backed by an ordered set of RE-matching rules which could be replaced and/or reordered and/or supplemented in User prop files?
You would probably want to have friendly "meta" names for, say, the first three [non-blank] lines and last [non-blank] line of the file.
BTW, I had wanted to use this scheme outside of just files that start with "#!", but a quick survey of c/c++, OCaml, php, Python, Perl, Makefile, properties, css, html... files quickly put an end to that!
So, whatever "auto" scheme is adopted, it probably makes the most sense if the circumstances under which it will be applied are well-defined... and limited (notwithstanding the "always (allow override of extension)" above).
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scite-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scite-interest
