I've never written a lexer before so I don't know how this would fit into the 'grand scheme' of things, but how about making 'file type detection' part of the lexer? Every lexer would have a 'virtual' function (not sure if a lexer is implemented like that, otherwise it would just have a function in its interface, you get the idea) that would take two arguments ('first line' and 'last line') and would return a bool. The lexer then decides, based on the contents of the first and last line, whether it can be used for coloring that file (return true) ort not (return false). Upon startup, scite would loop over all available/enabled lexers (those listed in the menu, I presume) and call the function on every one of them, stopping when one returns 'true'. No futzing with extra settings per lexer, at most one global variable to turn 'auto-detection' on or off. For example the bash lexer could check for /#!\/.*sh/ and a php lexer for /<?(php)?/ (if they were to choose a regex solution, that is). Just an idea.

cheers,

roel


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.

   Neil

_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest


_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest

Reply via email to