3 ms·

Web browsers line break text dynamically just fine - as do, well, text editors. Using a text editor to automatically embed line breaks doesn't fix the problem:

by chris_7 10y ago

Web browsers line break text dynamically just fine - as do, well, text editors. Using a text editor to automatically embed line breaks doesn't fix the problem: embedding line breaks in text for formatting is wrong semantically. Hard line breaks should mean something. Now I can't reflow the text to display it on a web page in a normal font, because I can't be sure of which line breaks are meaningful, and which are formatting.

masklinn 10y ago
Except now you need everything to handle textual contexts because while I do want my nice paragraph of text to be wrapped, I don't want my code snippet to be wrapped at all, and I want my nested list to be correctly intended at wrapping.
- chris_7 10y ago
  Is there not precedent for handling that correctly in a plain text field?
  - falcolas 10y ago
    Which, in the case of HN and other pages, can either break the formatting of the entire page by pushing the right margin beyond the window, or artificially constrained windows which you need to scroll sideways on. Text layout is a hard problem. It's why TEX (and its derivatives) is still so damned useful (and complicated).
    - chris_7 10y ago
      It's really not that hard in this case. Don't wrap lines with a four-space prefix (or whatever format is decided), wrap lines without one. Allow users to disable the wrapping if they prefer wrapped code. The prefix can be stripped at display time if you wish, so that code is left-aligned - actually, since the formatting isn't encoded in the log, only the semantics, users can configure the display as they please. Possible handle lines beginning with - as lists and indent them correctly. If a message somehow breaks the format, do not accept it. This isn't TeX-level complexity.
- greenhatman 10y ago
  I guess we want to use markdown in commit messages then.
  - masklinn 10y ago
    That provides absolutely no help. Markdown-formatted messages doesn't give you a plain-text renderer and text layout engine.
deleted 10y ago
[deleted]

by chris_7 10y ago

masklinn 10y ago

Except now you need everything to handle textual contexts because while I do want my nice paragraph of text to be wrapped, I don't want my code snippet to be wrapped at all, and I want my nested list to be correctly intended at wrapping.

chris_7 10y ago
Is there not precedent for handling that correctly in a plain text field?
- falcolas 10y ago
  Which, in the case of HN and other pages, can either break the formatting of the entire page by pushing the right margin beyond the window, or artificially constrained windows which you need to scroll sideways on. Text layout is a hard problem. It's why TEX (and its derivatives) is still so damned useful (and complicated).
  - chris_7 10y ago
    It's really not that hard in this case. Don't wrap lines with a four-space prefix (or whatever format is decided), wrap lines without one. Allow users to disable the wrapping if they prefer wrapped code. The prefix can be stripped at display time if you wish, so that code is left-aligned - actually, since the formatting isn't encoded in the log, only the semantics, users can configure the display as they please. Possible handle lines beginning with - as lists and indent them correctly. If a message somehow breaks the format, do not accept it. This isn't TeX-level complexity.
greenhatman 10y ago
I guess we want to use markdown in commit messages then.
- masklinn 10y ago
  That provides absolutely no help. Markdown-formatted messages doesn't give you a plain-text renderer and text layout engine.

deleted 10y ago

[deleted]