4 ms·
Counterpoint from Linus Torvalds regarding wrapping text for git commit messages: [0] > Word-wrapping is a property of the text. And the tool you use to visual
by MaxBarraclough 5y ago
Counterpoint from Linus Torvalds regarding wrapping text for git commit messages: [0]
> Word-wrapping is a property of the text. And the tool you use to
visualize things cannot know. End result: you do word-wrapping at the
only stage where you can do it, namely when writing it. Not when
showing it.
> Some things should not be word-wrapped. They may be some kind of
quoted text - long compiler error messages, oops reports, whatever.
Things that have a certain specific format.
> The tool displaying the thing can't know. The person writing the
commit message can. End result: you'd better do word-wrapping at
commit time, because that's the only time you know the difference.
[0] https://github.com/torvalds/linux/pull/17#issuecomment-5661185 https://github.com/torvalds/linux/pull/17#issuecomment-56611...
edit I realise there's some irony in the malformed '>' quotation notation I'm using here. The alternative would be to use a paragraph per line to force the HackerNews formatting to present each quoted line on its own line (i.e. its own paragraph) but that would leave nothing to indicate the end of each paragraph.
- mrob 5y ago>They may be some kind of quoted text - long compiler error messages, oops reports, whatever. Things that have a certain specific format. In the contexts where it matters, the display software can mark each linebreak it inserts with a special symbol that's not found in plain text (possible even in terminal apps, e.g. by using inverted color) to indicate it wasn't found in the original text. Unlike pre-formatting text, this does not lose information.
- MaxBarraclough 5y agoWhat you've described isn't plain text.
- mrob 5y agoIt's a method of displaying plain text that distinguishes between original linebreaks and linebreaks inserted by the display software. The text itself is 100% plain.