4 ms·
That software is called a text editor and you can configure it to do the text wrapping for you. More seriously, it is quite hard to wrap text correctly after y
by raimue 10y ago
That software is called a text editor and you can configure it to do the text wrapping for you.
More seriously, it is quite hard to wrap text correctly after you submitted it. For example people add manual line breaks for structuring text and to separate things like quoted commands from the rest. It would be much more cumbersome to go back after a git commit to fix this, probably in multiple iterations until you get the intended presentation instead of just doing it right from the start.
- chris_7 10y agoWeb 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 agoExcept 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 agoIs there not precedent for handling that correctly in a plain text field?
- falcolas 10y agoWhich, 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 agoIt'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 agoI guess we want to use markdown in commit messages then.
- masklinn 10y agoThat provides absolutely no help. Markdown-formatted messages doesn't give you a plain-text renderer and text layout engine.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- BurningFrog 10y agoOPs point remains. It's git's job to tell me its limitations. Not my job to adapt my tools to it. When practical, of course. In this case, git could simply give a "are you sure you want to commit with these long lines?" warning.
- petepete 10y agoGit copes just fine with long commit messages. Providing the rest of your team is happy with it and your tools can display it ok, just do it.
- usea 10y agoAgreed. My last two jobs had no line length limit on commit messages (or code) and it was great. But culturally, C# developers don't live in an 80-column terminal window, either.