4 ms·

The point is that people shouldn't be littering their text with hard line breaks just to support software that can't do word-wrapping properly. That your editor

The point is that people shouldn't be littering their text with hard line breaks just to support software that can't do word-wrapping properly. That your editor can do this doesn't mean you should. It might make the text look a bit prettier in an 80 column terminal, but it makes it worse pretty much anywhere else.

masklinn 10y ago
> The point is that people shouldn't be littering their text with hard line breaks just to support software that can't do word-wrapping properly. How can the software guess whether a given line should be wrapped (text), should not be wrapped (code), should be wrap-indented (list item) or should be wrap-prefixed (quote block) when it's only given raw bytes assumed to be text without further information?
- aninhumer 10y ago
  >should not be wrapped (code) I'm not sure why this matters much? If the code doesn't fit on the screen you're viewing it on, then it's not going to be convenient to read regardless of whether you wrap it or have a horizontal scroll. >should be wrap-indented When would you have an indented line that shouldn't be wrap-indented?
  - masklinn 10y ago
    > I'm not sure why this matters much? Because wrapped code is generally nonsensical. > If the code doesn't fit on the screen you're viewing it on, then it's not going to be convenient to read Inconvenient is one thing, nonsensical is an other. > When would you have an indented line that shouldn't be wrap-indented? That's noted right after, in the parens: list items. This is not correct wrapping for a list item: * this is a list item this is correct wrapping for a list item: * this is a list item If the display software does not do that (and I'm reasonably certain most would not) I'd much rather properly hard-wrap my text before committing it, that way I know that it will end up correctly wrapped and actually readable.
    - aninhumer 10y ago
      >Because wrapped code is generally nonsensical. Not really? It's probably slightly more awkward to read than scrolling, but then, the solution is to read code on an appropriately sized screen in the first place. And incidentally, truncated code definitely is nonsensical. >List items. They can be handled as you mention, but it's hardly the worst thing in the world if they're not. And if you really care about formatting this much, you should use a format that encodes it properly (e.g. Markdown) instead of producing the text equivalent of a PDF.
      - masklinn 10y ago
        > Not really? Yes really. > but then, the solution is to read code on an appropriately sized screen in the first place. That's not a solution to anything. > And incidentally, truncated code definitely is nonsensical. Truncated code is visibly truncated, not nonsensical garbage right next to actual code. > They can be handled as you mention And the software knows what a list item is… how? > it's hardly the worst thing in the world if they're not. One more fantastic non-solution to listed problems, we're definitely going places. > And if you really care about formatting this much, you should use a format that encodes it properly (e.g. Markdown) instead of producing the text equivalent of a PDF. So you're saying git should embed a markdown renderer and text layout engine?
        aninhumer 10y ago
        >That's not a solution to anything. I'm not sure what scenario you're imagining where you absolutely have to read code in commit messages on an unreasonably narrow screen, and you can't wait until you have an appropriate machine. But if a scenario occurred where that were important, I'm sure you'd manage to read some wrapped code, it's not that hard. >Truncated code is visibly truncated Unless it's not, because there's ` + someExtraStuff` just off the end. >So you're saying git should embed a markdown renderer and text layout engine? If you really want pristinely formatted commit messages that badly then yes.
        10y ago
- chris_7 10y ago
  Markdown renderers seem perfectly capable of this. git wouldn't even need to disambiguate asterisk for lists vs. asterisk for emphasis.
  - masklinn 10y ago
    So every piece of software now needs a markdown renderer?
    - chris_7 10y ago
      If Linus wants a consistent commit message format, he should enforce it at the software level, rather than hoping people read a comment he left in a repository about logging his swimming information. This does not mean that the format needs to be Markdown (which includes embedded HTML, so obviously not Markdown), or that all software needs a Markdown renderer. I'm not sure why you'd conclude that.
      - wruza 10y ago
        Enforcing is an administrative task committed by specific people in specific projects (there is a thing called 'best practice', but it never is a hard rule). Tools authors should not enforce anything, it's not their job, responsibility and competence, even if a particular project like Linux has the same Linus for both project management / rcs tool writing.
    - Avshalom 10y ago
      we don't even need markdown. Groff and less are already there and already handle formatting and reflowing just fine.
      - masklinn 10y ago
        Groff is a text processing/formatting system so same issue, and less doesn't handle jack shit.
makecheck 10y ago
Except that almost every time, I am composing and viewing the log messages from a terminal. The logical thing for a web page to do is to display logs as “preformatted” text (because they are, same as code). It would be interesting to have a way to indicate a formatting style when composing a log message though; for instance, a way to indicate that a log contains Markdown code.
wruza 10y ago
On the other hand, non-terminal people should not use terminal-oriented software along with flowing text ideology. We do not even distinguish line breaks / paragraph breaks for now (though we often emulate that via \n\n). We do not have add-indent-level and cut-indent-level character codes for to not mess with indent. Markdown may seem good, but it is still low-level format, like rtf or html; it isn't natural in any way. We just pretend that good old-and-new Unix tools are perfectly applicable to modern textual fashion, when they really aren't. That said, it is arguable if we must do that step forward from the development perspective. These tools already solved real issues, and now we discuss preferences. Personally, I'm fine with terminal on the left and wrap-capable editor on the right. It's not "to support software", I really like it more.

masklinn 10y ago

> The point is that people shouldn't be littering their text with hard line breaks just to support software that can't do word-wrapping properly. How can the software guess whether a given line should be wrapped (text), should not be wrapped (code), should be wrap-indented (list item) or should be wrap-prefixed (quote block) when it's only given raw bytes assumed to be text without further information?

aninhumer 10y ago
>should not be wrapped (code) I'm not sure why this matters much? If the code doesn't fit on the screen you're viewing it on, then it's not going to be convenient to read regardless of whether you wrap it or have a horizontal scroll. >should be wrap-indented When would you have an indented line that shouldn't be wrap-indented?
- masklinn 10y ago
  > I'm not sure why this matters much? Because wrapped code is generally nonsensical. > If the code doesn't fit on the screen you're viewing it on, then it's not going to be convenient to read Inconvenient is one thing, nonsensical is an other. > When would you have an indented line that shouldn't be wrap-indented? That's noted right after, in the parens: list items. This is not correct wrapping for a list item: * this is a list item this is correct wrapping for a list item: * this is a list item If the display software does not do that (and I'm reasonably certain most would not) I'd much rather properly hard-wrap my text before committing it, that way I know that it will end up correctly wrapped and actually readable.
  - aninhumer 10y ago
    >Because wrapped code is generally nonsensical. Not really? It's probably slightly more awkward to read than scrolling, but then, the solution is to read code on an appropriately sized screen in the first place. And incidentally, truncated code definitely is nonsensical. >List items. They can be handled as you mention, but it's hardly the worst thing in the world if they're not. And if you really care about formatting this much, you should use a format that encodes it properly (e.g. Markdown) instead of producing the text equivalent of a PDF.
    - masklinn 10y ago
      > Not really? Yes really. > but then, the solution is to read code on an appropriately sized screen in the first place. That's not a solution to anything. > And incidentally, truncated code definitely is nonsensical. Truncated code is visibly truncated, not nonsensical garbage right next to actual code. > They can be handled as you mention And the software knows what a list item is… how? > it's hardly the worst thing in the world if they're not. One more fantastic non-solution to listed problems, we're definitely going places. > And if you really care about formatting this much, you should use a format that encodes it properly (e.g. Markdown) instead of producing the text equivalent of a PDF. So you're saying git should embed a markdown renderer and text layout engine?
      - aninhumer 10y ago
        >That's not a solution to anything. I'm not sure what scenario you're imagining where you absolutely have to read code in commit messages on an unreasonably narrow screen, and you can't wait until you have an appropriate machine. But if a scenario occurred where that were important, I'm sure you'd manage to read some wrapped code, it's not that hard. >Truncated code is visibly truncated Unless it's not, because there's ` + someExtraStuff` just off the end. >So you're saying git should embed a markdown renderer and text layout engine? If you really want pristinely formatted commit messages that badly then yes.
        10y ago
chris_7 10y ago
Markdown renderers seem perfectly capable of this. git wouldn't even need to disambiguate asterisk for lists vs. asterisk for emphasis.
- masklinn 10y ago
  So every piece of software now needs a markdown renderer?
  - chris_7 10y ago
    If Linus wants a consistent commit message format, he should enforce it at the software level, rather than hoping people read a comment he left in a repository about logging his swimming information. This does not mean that the format needs to be Markdown (which includes embedded HTML, so obviously not Markdown), or that all software needs a Markdown renderer. I'm not sure why you'd conclude that.
    - wruza 10y ago
      Enforcing is an administrative task committed by specific people in specific projects (there is a thing called 'best practice', but it never is a hard rule). Tools authors should not enforce anything, it's not their job, responsibility and competence, even if a particular project like Linux has the same Linus for both project management / rcs tool writing.
  - Avshalom 10y ago
    we don't even need markdown. Groff and less are already there and already handle formatting and reflowing just fine.
    - masklinn 10y ago
      Groff is a text processing/formatting system so same issue, and less doesn't handle jack shit.

makecheck 10y ago

Except that almost every time, I am composing and viewing the log messages from a terminal. The logical thing for a web page to do is to display logs as “preformatted” text (because they are, same as code). It would be interesting to have a way to indicate a formatting style when composing a log message though; for instance, a way to indicate that a log contains Markdown code.

wruza 10y ago

On the other hand, non-terminal people should not use terminal-oriented software along with flowing text ideology. We do not even distinguish line breaks / paragraph breaks for now (though we often emulate that via \n\n). We do not have add-indent-level and cut-indent-level character codes for to not mess with indent. Markdown may seem good, but it is still low-level format, like rtf or html; it isn't natural in any way. We just pretend that good old-and-new Unix tools are perfectly applicable to modern textual fashion, when they really aren't. That said, it is arguable if we must do that step forward from the development perspective. These tools already solved real issues, and now we discuss preferences. Personally, I'm fine with terminal on the left and wrap-capable editor on the right. It's not "to support software", I really like it more.