Hi Dennis,

I'd write a unit test and invoke the lexer for sample input. The tokens
provide a useful toString so adding all of the to an arraylist and
inspecting this one may be helpful. This (propably sort of outdated)
blog post may provide some inspiration:
http://blogs.itemis.de/stundzig/archives/726

terminal fragment WS_CHAR:
    ' ' | '\t' | '\r' | '\n';

terminal UNQUOTED_STRING:
    !'"' (!('"' | WS_CHAR))*;

terminal fragment UNQUOTED_STRING_FIRST_CHARACTER:
    ('a'..'z' | 'A'..'Z');

terminal fragment UNQUOTED_STRING_OTHER_CHARACTERS:
    (UNQUOTED_STRING_FIRST_CHARACTER | '0'..'9' | '.' | '_' | '-' | '\\');

terminal UNQUOTED_STRING:
    (UNQUOTED_STRING_FIRST_CHARACTER) (UNQUOTED_STRING_OTHER_CHARACTERS)*;

Hi,

is there a reason, you can't make your unquoted string definition a datatype rule rather than a terminal rule?

Character ranges, wildcards, the until token and the negation as well as the EOF token are only available for terminal rules.

Use of data rules is good unless you end up with lots of tiny tokens,
have to have long lists of things to include (because 'not' is not
possible), or end up with lots of fiddling with hidden on/off (which has
subtle unwanted effects in several places).

When you reach that point, you can write a more powerful external lexer.
Thought that could be good to know if you start feeling you are digging
yourself into a hole.