On 10/25/2018 09:24 AM, Logan Smyth wrote:
Yeah, /LineTerminatorSequence/ is definitely the canonical definition of line
numbers in JS at the moment. As we explore
https://github.com/tc39/proposal-error-stacks, it would be good to clearly
specify how a line number is computed from the original source. As currently
specified, a line number in a stack trace takes U+2028/29 into account, and
thus requires any consumer of this source code and line number value needs to
have a special case for JS code. It seems unrealistic to expect every piece of
tooling that works with source code would have a special case for JS code to
take these 2 characters into account. Given that, the choices are
1. Every tool that manipulates source code needs to know what type so it can
special-case JS it is in order to process line-related information
2. Every tool should consider U+2028/29 newlines, causing line numbers to be
off in other programming languages
2. Accept that tooling and the spec will never correspond and the use of these
two characters in source code will continue to cause issues
3. Diverge the definition of current source-code line from the current
/LineTerminatorSequence/ lexical grammar such that source line number is always
/\r?\n/, which is what the user is realistically going to see in their editor
The Unicode standard is the more relevant one here. Choice 2 is the correct
one per the Unicode standard. Tools that do not consider U+2028/29 to be line
breaks are not behaving as they should according to the latest Unicode standard.
Waldemar
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
