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?
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?
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 a list
item
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.
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?
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.
Mate, I already have pristinely formatted commit messages, because I format them as I desire.
You are the person telling me I shouldn't be formatting my messages and a nebulous "software" ought do that, the burden's on you to give them the tools which yield the same pristinely formatted output I already achieve without a formatted input.
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.
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.
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.