4 ms·

That seems like an obviously bad solution. That is like writing [a(b{c]d}e) except that the quote characters look even more similar.

brnt 7y ago
Its easy (solved) to map Unicode to control characters such as quotes (and when you think about it, quotes are often there to deal with ambiguities stemming from the limited number of allowed characters in ASCII). So to could have a terminal accepting such input, and a few helper function that normalize it into ASCII and so on. After all, users of non-ascii languages (which is nearly everyone) already know how to deal with it without ambiguity. Its only ambiguous if you don't use encodings, and that should never happen anyway.
- diffeomorphism 7y ago
  > and a few helper function that normalize it into ASCII and so on If you are going to get rid of it anyways, why bother with it in the first place? Also, you then have the ambiguity/problem whether some symbols are mapped to the same ones or not. > already know how to deal with it without ambiguity I wish. Just dealing with ü vs ue vs \"u and ascii, win something, utf8 and utf16 is still annoying in practice. Or latex choking on accents, non-breaking whitespace or similar fun stuff.
  - brnt 7y ago
    The argument to do it is it democratizes users with their scripts around the world (and solve the issue of having 'the wrong' quote). Normalization solves the latter. It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate.
    - diffeomorphism 7y ago
      I disagree, it simply tells everyone they are wrong and the "normalized" one is the right one. Oh, you used foo and föö as variable names, too bad those are the same now by normalization. > It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate. Tone down the condescension and insults, please.

brnt 7y ago

Its easy (solved) to map Unicode to control characters such as quotes (and when you think about it, quotes are often there to deal with ambiguities stemming from the limited number of allowed characters in ASCII). So to could have a terminal accepting such input, and a few helper function that normalize it into ASCII and so on. After all, users of non-ascii languages (which is nearly everyone) already know how to deal with it without ambiguity. Its only ambiguous if you don't use encodings, and that should never happen anyway.

diffeomorphism 7y ago
> and a few helper function that normalize it into ASCII and so on If you are going to get rid of it anyways, why bother with it in the first place? Also, you then have the ambiguity/problem whether some symbols are mapped to the same ones or not. > already know how to deal with it without ambiguity I wish. Just dealing with ü vs ue vs \"u and ascii, win something, utf8 and utf16 is still annoying in practice. Or latex choking on accents, non-breaking whitespace or similar fun stuff.
- brnt 7y ago
  The argument to do it is it democratizes users with their scripts around the world (and solve the issue of having 'the wrong' quote). Normalization solves the latter. It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate.
  - diffeomorphism 7y ago
    I disagree, it simply tells everyone they are wrong and the "normalized" one is the right one. Oh, you used foo and föö as variable names, too bad those are the same now by normalization. > It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate. Tone down the condescension and insults, please.