oAW has moved to Eclipse.

The built in STRING definition is incorrect, I think. In the generated ANTLR file, it is:

RULE_STRING :
  '"' ( '\\' ('b'|'t'|'n'|'f'|'r'|'\"'|'\''|'\\') | ~('\\'|'"') )* '"' |
  '\'' ( '\\' ('b'|'t'|'n'|'f'|'r'|'\"'|'\''|'\\') | ~('\\'|'\'') )* '\''
;

RULE_STRING :
  '"'<--- not escaped  ( '\\' ('b'|'t'|'n'|'f'|'r'|'\"' <--- escaped |'\''|'\\') 
      | ~('\\'|'"' <--- not escaped ) )* '"'<--- not escaped  |
  '\'' ( '\\' ('b'|'t'|'n'|'f'|'r'|'\"' <--- escaped |'\''|'\\') | ~('\\'|'\'') )* '\''
;

Native DoubleQuotedStringLiteral
  :  " '\"' ~('\"')* '\"' "
  ;

The fix will appear in the next nightly build.

Actually, concerning the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=243608, which now should be fixed in the CVS, the strings with backslashed quotes used to work correctly as before (the parser used to parse it correctly), it was the highlighter that was wrong...

I already fixed the highlighter some weeks ago, as far as I remember.

Yes, I had provided a patch in that bug report.

But I just wanted to point out that it was not related to the parser rule (which worked correctly) but to the highlighter rule (which did not take into consideration the escape char).

Does my change hurt? Should I change it back?

If you refer to the change based on my patch, I think that patch is correct: it fixes the highlighter.

Also the ANTLR rule is correct, as far as I know

I could be wrong, but if the previous ANTLR rule was correct, shouldn't it be possible to have the following rule in an xText file?

Native DoubleQuotedStringLiteral
  :  " '\"' ~('\"')* '\"' "
  ;

I just triggered a new build manually.

Native DoubleQuotedStringLiteral
  :  " '"' ~('"')* '"' "
  ;

"string with \" escaped quotes"

"string with \"

Normally, you would be correct. However, in the particular case that I'm using, I'm trying to parse a string that doesn't use '\' as an escape character. Someone gave me files with entries like:

file "C:\path\to\file.txt"

Where the backslashes are not escaped, and there aren't any special characters like \t, \r, etc.

The thing that makes it difficult is that there are also "normal" strings in the file as well, but consistently in a different context. So, I need rules that parse both cases for the same file. It's one of those situations where I wish I could have had the files uses consistent strings in the first place :)

-- Scott

Sorry, now I see your point