Closed patrickrgaffney closed 8 years ago
There are some major changes in PR #19 including one for parsing floating point: a0cc5e794a21cdcd3a08a3ac124f9382f3c55114
Though with this commit I see 1.21875p1
marked as invalid.
/cc @jtbandes
It's my understanding that 1.21875p1
should be invalid. Hex floating point literals must start with 0x
.
It's my understanding that
1.21875p1
should be invalid. Hex floating point literals must start with0x
.
That is correct, the p
should be and e
: 1.21875e1
. Just a typo on my part.
This is still incorrect using the current syntax definitions, haven't tested using PR #19.
19 should fix these issues. Do try it out if you get a chance :) On Tue, Sep 6, 2016 at 8:35 AM Pat Gaffney notifications@github.com wrote:
It's my understanding that 1.21875p1 should be invalid. Hex floating point literals must start with 0x.
That is correct, the p should be and e: 1.21875e1. Just a typo on my part.
This is still incorrect using the current syntax definitions, haven't tested using PR #19 https://github.com/textmate/swift.tmbundle/pull/19.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/textmate/swift.tmbundle/issues/20#issuecomment-244991078, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA3nSvlxnwEJirH5sbnEwhOrbI_ydPfks5qnYhDgaJpZM4J17Wd .
19 should fix these issues.
Beautiful. Performing the git clone
now. Thanks! 👍🏽
This fix has now been pushed to the bundle, thanks for the report!
It seems like floating-point literals are not being parsed correctly.
For example, taken from the Swift Programming Language book:
The
decimalDouble
variable appears to be parsing correctly at first, but after trying to figure out whyexponentDouble
andhexadecimalDouble
were not being parsed, i realized the following: All floating-point literals are being parsed as twointeger.decimal
's separated by aoperator.custom.postfix.unary
. Basically, the decimal is always being parsed as aoperator.custom.postfix.unary
scope, thereforeexponentDouble
andhexadecimalDouble
aren't highlighted.The bizarre thing is that the regex for the three
floating-point-literal
scopes are correct — or, they would parse all three of these variables (tested in Patterns.app). And as far as I can tell, the#literal
patterns have a higher precedence than the#operators
patterns.I tried to fix this but was unsuccessful. Looking for any tips.