[haxe] Highlighting of ranges with underscore var names is broken

[Gama11]

0..._lines.length is using the default style.

Looks ok after adding a space:

This is probably regression is probably caused by the Scintilla update (#1041). I guess the cpp lexer lexes this as some new style that isn't defined in Haxe.xml.

The relevant part seems to be <number><underscore>, i.e. 0_ also looks like that.

[Meychi]

Its a user defined literal in CPP, we need to handle that.

[Meychi]

Hmm... it seems to follow gdefault, at least when running from dev.

[Gama11]

So you can't reproduce it?

[Meychi]

Which theme do you use?

[Gama11]

The default theme.

[Meychi]

It shows differently here. Im running standalone FD from dev.

We can fix this by adding it to our themes but it will not work in 3rd party themes.

@elsassph: Should we disable this in the custom Scintilla build for best compatibility?

[Meychi]

Even if we define this in theme it doesn't work. 0... gets coloured incorrectly. So i suggest disabling this or add it behind a scintilla property on our custom build.

[elsassph]

It sounds like Scintilla should be fixed to do a lookup and only allow one dot in a number... Or is that valid in some cpp-like language?

[Meychi]

Interger literals don't allow multiple dots but string literals do. I think Sci generalizes literals:

http://en.cppreference.com/w/cpp/language/user_literal

[Meychi]

The 64bit version of SciLexer is older and im wondering if we should revert to older version for now for faster 5.1 release?

If we want to add breaking config changes later like this or #1052 we could do all this after 5.1 for 5.2 in one go. What do you all think?

[Gama11]

I have no problems with it - if it helps speed up the release, go for it.

[Meychi]

Done. The commit can be reverted after we start the next dev cycle.