There’s a special circle of hell for the “This file contains ambigious Unicode characters” overlay on @Codeberg
No, it doesn’t, it uses proper curly quotes and other typographically-correct punctuation in comments and strings.
Thought we’d fixed this in Forgejo but apparently not?
Really making me not want to link to my source code on Codeberg and I don’t want to migrate elsewhere right now when everything else is working so well.
e.g., see https://codeberg.org/kitten/app/src/branch/parameter-objects/examples/markdown-preview/index.page.js
The non-ascii is yours: non-ascii apostrophes.
wget https://codeberg.org/kitten/app/raw/branch/parameter-objects/examples/markdown-preview/index.page.js
grep -E "Interestingly|updates while|sends a" index.page.js |od -c
0000040 342 200 231 s v a l u e h a s n
...
0000140 w , I 342 200 231 m g o i n g t
...
0000300 w e d o n 342 200 231 t w a n t
En.Wikipedia doesn 342 200 231 t want non-ascii apostrophes either [1] ;).
OK, it's clear you want to allow rendered quotation marks and apostrophes in source code strings and comments, as opposed to keeping the source in ascii and letting libraries (TeX or other) do the work of fancy rendering. I'm open to looking at the arguments both ways, though sticking to ascii seems to me more robust - except for i18n.
@aral @boud @Codeberg still don't like this. It's not clear in all cases which comments are prose versus which ones are code (i.e. meant to be uncommented in some circumstances, or intended to be found by a tool, like c pragma comments)
Keeping Unicode lookalikes out of source files, or warning when they're present, seem like wise security choices to me.