- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Open
Labels
parserLanguage parsing and surface syntaxLanguage parsing and surface syntax
Description
There's many invisible unicode characters.
https://invisible-characters.com/
We currently disallow several of them
Line 596 in c245179
(error (string "invisible character \\u" (number->string (fixnum c) 16) " near column " (+ 1 cn))) |
Namely
'\u00ad' # soft hyphen
'\u200b' # zero width space
'\u200c' # zero width non-joiner
'\u200d' # zero width joiner
'\u200e' # left-to-right mark
'\u200f' # right-to-left mark
'\u2060' # word joiner
'\u2061' # function application
It appears the reference parser also attempts to disallow '\u115f' # Hangul Choseong filler
, but this doesn't work due to Base.is_id_char
returning true for that character. I'm not sure this is a problem, I didn't find obvious information about what this filler character is for and whether it might be required for writing identifiers in Korean.
Anyway, should we disallow more of the list from https://invisible-characters.com/ ?
Metadata
Metadata
Assignees
Labels
parserLanguage parsing and surface syntaxLanguage parsing and surface syntax
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
inkydragon commentedon May 17, 2023
Maybe we could just disallow all those invisible characters.
Wait until we find a use for certain characters, or when someone complains that certain characters are not available, and then we could relax those restrictions.
We could also introduce a new function to detect whether a particular character is visible or not. Perhaps called
isInvisibleCharacter
.And a longer list in VSCode: https://github.com/microsoft/vscode/blob/44a490b514be5972328549ea4a634d4d1587ae2c/src/vs/base/common/strings.ts#L1192-L1193
ref: flopp/invisible-characters#1
c42f commentedon May 18, 2023
Awesome, thanks for the pointer to the list from VSCode. I definitely didn't want to trawl through the unicode standard myself looking for those!
It seems reasonable to me to just add the big list and wait to see whether it's any problem in practice. I'm ... almost ... willing to bet there's no code in General which uses these (except for the ascii whitespace)
Seelengrab commentedon May 18, 2023
I think lots of these fillers are a remnant of converting KS X 1001 to Unicode. As far as I can tell, it shouldn't be produced in a unicode environment at all, according to this unicode document (at least the Hangul Filler). They're in principle allowed because they're in the
Letter, Other
category.As mentioned when this kind of thing came up in the discussion surrounding bidi confusion here, I don't think disallowing these on the language level is the right place - it seems more appropriate for a linter.