3 ms·
They cover the reasoning for using the control picture characters instead of the control characters in the FAQ: "We tried using the control characters, and als
by SigmundurM 3y ago
They cover the reasoning for using the control picture characters instead of the control characters in the FAQ:
"We tried using the control characters, and also tried configuring various editors to show the control characters by rendering the control picture characters.
First, we encountered many difficulties with editor configurations, attempting to make each editor treat the invisible zero-width characters by rendering with the visible letter-width characters.
Second, we encountered problems with copy/paste functionality, where it often didn't work because the editor implementations and terminal implementations copied visible letter-width characters, not the underlying invisible zero-width characters.
Third, users were unable to distinguish between the rendered control picture characters (e.g. the editor saw ASCII 31 and rendered Unicode Unit Separator) versus the control picture characters being in the data content (e.g. someone actually typed Unicode Unit Separator into the data content)."
- https://github.com/SixArm/usv/tree/main/doc/faq#why-use-control-picture-characters-rather-than-the-control-characters-themselves https://github.com/SixArm/usv/tree/main/doc/faq#why-use-cont...
- nostrademons 3y agohttps://xkcd.com/927/ https://xkcd.com/927/
- pie_flavor 3y ago'Too many competing standards' is not one of the quoted reasons.
- ascorbic 3y agohttps://github.com/SixArm/usv/blob/main/doc/criticisms/index.md#xkcd-one-universal-standard https://github.com/SixArm/usv/blob/main/doc/criticisms/index...
- vidarh 3y agoI can't read those characters at the size I can/prefer to read the text at, so I need the tooling to support and render these differently anyway... This feels like solving the wrong problem in a way that will still end up with the same amount of work.