4 ms·
Simpler for the text editor logic, not necessarily simpler for the encoder/decoder. > If it supports all of Unicode it's not simpler. The point is that it doe
by Findecanor 2y ago
Simpler for the text editor logic, not necessarily simpler for the encoder/decoder.
> If it supports all of Unicode it's not simpler.
The point is that it doesn't. The Unicode that it does not handle should get marked as "illegal character", rendered as boxes and not get mangled unless the user messes with it.
Support for more of Unicode could be added incrementally, and in a single subsystem instead of everywhere in the text editor.
- crazygringo 2y agoI still don't understand what you're arguing for. >> If it supports all of Unicode it's not simpler. > The point is that it doesn't. But then it doesn't work. Why would you not want to support all of Unicode? > The Unicode that it does not handle should get marked as "illegal character", rendered as boxes and not get mangled unless the user messes with it. That's what already happens. We already show boxes when the codepoint is unknown or there's no glyph in the font. Their codepoints are preserved. > Support for more of Unicode could be added incrementally, and in a single subsystem instead of everywhere in the text editor. It already is. New OS's get upgraded to new Unicode versions. Text editors don't usually have to change a thing. I don't know what problem you're trying to solve here.