←back to thread

CRLF is obsolete and should be abolished

(fossil-scm.org)
422 points km | 10 comments | 13 Oct 24 19:16 UTC | HN request time: 0.813s | source | bottom
1. Ekaros ◴[13 Oct 24 20:19 UTC] No.41831220[source]▶
I think I can offer most reasonable compromise here. Decide upon on new UTF-8 code point. Have the use mandated and ignore and ban all end-points that do not use this code-point instead of CRLF or just LF alone.
replies(6): >>41831264 #>>41831281 #>>41831818 #>>41831843 #>>41832264 #>>41832462 #
2. phkahler ◴[13 Oct 24 20:24 UTC] No.41831264[source]▶
So break everything.
3. whizzter ◴[13 Oct 24 20:26 UTC] No.41831281[source]▶
https://xkcd.com/927/
4. kps ◴[13 Oct 24 21:33 UTC] No.41831818[source]▶
You mean U+2028 LINE SEPARATOR?
replies(2): >>41831844 #>>41831854 #
5. bear8642 ◴[13 Oct 24 21:36 UTC] No.41831843[source]▶
> Decide upon on new UTF-8 code point.

Unicode have already done so - (NEL) https://www.compart.com/en/unicode/U+0085

6. Ekaros ◴[13 Oct 24 21:36 UTC] No.41831844[source]▶
Perfect. So now we just need to start filing bug reports to any tool that does not support it instead of CRLF or LF alone.
replies(1): >>41834208 #
7. bear8642 ◴[13 Oct 24 21:37 UTC] No.41831854[source]▶
Oh, yet another option - first thought was U+0085 NEXT LINE as above
8. ◴[13 Oct 24 22:28 UTC] No.41832264[source]▶
9. nycdotnet ◴[13 Oct 24 22:54 UTC] No.41832462[source]▶
Which would need to be encoded in at least two bytes at which point, why not just use CRLF?
10. ◴[14 Oct 24 04:32 UTC] No.41834208{3}[source]▶