codemirror/codemirror5
1
0
Fork 0
Code Issues 412 Pull requests Activity

Dart: support digit separators #14263

Merged
marijnh merged 1 commit from github/fork/srawlins/dart-digit-separators into master 2024-09-05 16:45:25 +02:00
Conversation 4 Commits 1 Files changed 1 +2
marijnh commented 2024-09-05 02:49:51 +02:00 (Migrated from gitlab.com)
Copy link

Dart is adding support for digit separators, the underscore, like 1_000_000 or 0x33_33_33. The Dart playground, DartPad, still runs on codemirror5, so this would be a welcome fix.

Dart is [adding support for digit separators](https://github.com/dart-lang/language/blob/main/working/digit-separators/feature-specification.md), the underscore, like `1_000_000` or `0x33_33_33`. The Dart playground, [DartPad](https://dartpad.dev/), still runs on codemirror5, so this would be a welcome fix.
marijnh commented 2024-09-05 06:55:04 +02:00 (Migrated from gitlab.com)
Copy link

That regexp seems to allow underscores anywhere, whereas the linked proposal only allows them between digits. I think this'll make _ tokenize as a number, which doesn't seem right.

That regexp seems to allow underscores anywhere, whereas the linked proposal only allows them between digits. I think this'll make `_` tokenize as a number, which doesn't seem right.
marijnh commented 2024-09-05 16:40:50 +02:00 (Migrated from gitlab.com)
Copy link

As I understand it, the number pattern is only checked when we see numberStart, line 65 in clike.js. With manual testing, I see that _ is styled as a "variable."

As for other spots where _ is not allowed (e.g. in 1_._0, neither underscore is allowed), I think it is fine to allow them for the purposes of in-progress typing, and error-recovery. For example, in the Dart parser, we parse 1_._0 as a number literal, and also report an error. This reduces errors-carried-forward. And for a trailing _ like 100_, it is fine to allow it for code-in-progress.

If you think we should be more strict here and only parse error-free numbers as numbers, I can amend the PR.

As I understand it, the `number` pattern is only checked when we see `numberStart`, line 65 in `clike.js`. With manual testing, I see that `_` is styled as a "variable." As for other spots where `_` is not allowed (e.g. in `1_._0`, neither underscore is allowed), I think it is fine to allow them for the purposes of in-progress typing, and error-recovery. For example, in the Dart parser, we _parse_ `1_._0` as a number literal, and also report an error. This reduces errors-carried-forward. And for a trailing `_` like `100_`, it is fine to allow it for code-in-progress. If you think we should be more strict here and only parse error-free numbers as numbers, I can amend the PR.
marijnh commented 2024-09-05 16:45:25 +02:00 (Migrated from gitlab.com)
Copy link

Merged by: marijnh at 2024-09-05 14:45:25 UTC

*Merged by: marijnh at 2024-09-05 14:45:25 UTC*
marijnh (Migrated from gitlab.com) closed this pull request 2024-09-05 16:45:25 +02:00
marijnh (Migrated from gitlab.com) merged commit into master 2024-09-05 16:45:25 +02:00
marijnh commented 2024-09-05 16:45:53 +02:00 (Migrated from gitlab.com)
Copy link

Oh, indeed, there's a separate regexp for the start of the number. Then this is close enough, indeed.

Oh, indeed, there's a separate regexp for the start of the number. Then this is close enough, indeed.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
codemirror/codemirror5!14263
No description provided.