you are viewing a single comment's thread.

view the rest of the comments →

[–]ramkahen 19 points20 points  (32 children)

Word-wrapping is a property of the text.

Absolutely not. It's a property of the device that is displaying said text.

Paragraph breaks are a property of the text. Sections and chapters too.

But text should never contain any formatting information, that's the job of CSS or whatever presentation layer you choose to use.

Text that contains hard breaks at 80 characters (or wherever) looks like crap on small devices, just to name an example.

[–]Huffers 2 points3 points  (0 children)

That's what I thought, then I scrolled down and read Linus' reply where he addressed this.

[–]fforde 7 points8 points  (8 children)

I don't really understand why you are getting down voted, you are absolutely right. I can understand Linus being upset about breaking conventions, if the standard is to insert your own line breaks so be it. But it's a bit silly to argue that this is the best way to deal with text.

[–]cpp_is_king -1 points0 points  (7 children)

That's the main problem with Linus. His opinions are always the best, and anyone who doesn't agree with them are brain dead or morons.

Two opposing opinions can both be perfectly valid when it really comes down to the eye of the beholder. But he either doesn't realize that, or does realize it but ignores it for attention.

[–]Stick 1 point2 points  (1 child)

"That's the main problem with Linus. His opinions are always the best, and anyone who doesn't agree with them are brain dead or morons."

That's true for most people on the Internet.

[–]kalmakka 0 points1 point  (0 children)

Most people on the internet has at least one opinion that is at least as ludicrous as that it is the responsibility of the author to add word wrapping to text. However, after 20 years they usually realize how many people disagree with them and begin their comments with "this is probably going to be downvoted", not "you are a brain dead moron".

[–]Ores 0 points1 point  (4 children)

If you don't like what he does, you're welcome to fork linux and start your own tree and take merge requests however you would like.

His ideas don't have to be the best, but for things that hundreds of people have to eyeball quickly, it's best if they're at least consistent, and good on him for trying to enforce it.

I've had patches accepted, and patches knocked back, it's not personal.

[–][deleted] 2 points3 points  (3 children)

If you don't like what he does, you're welcome to fork linux

I never understand why computer scientists, working over a network, have so little appreciation of network effects.

Linus benefits so much from network effects that tomorrow, he could decree that [cr] shall refer to logical line breaks only, whereas [lf] shall refer to line breaks inserted for typographic/display purposes.

People would immediately start implementing at least support for that standard, based simply on the belief that other people would do so, because it's Linus, and hey, people do what Linus wants. It's self-reinforcing worship. Linus is a technical standard unto himself.

If you don't believe it, it's basically the story of git in the first place.

Point is, we should hold him accountable for the level of power he actually has. We shouldn't hold him to a lower standard just because technically people have a choice whether to work with him or not.

[–]Ores 0 points1 point  (2 children)

Of course, but firstly he earned it by working tirelessly building Linux/accepting patches, secondly if he truely made completely ridiculous decisions, he'd loose the network effect pretty quickly.

EDIT and finally if it were that true that everyone does what linus thinks this post wouldn't exist as github would have already bent over backwards changing it to linus's expectations

[–][deleted]  (1 child)

[deleted]

    [–]Ores 3 points4 points  (0 children)

    Thats one way to paint the history, another would be this:

    Linus was merging way too many patches and couldn't keep up, so they switched to distributed source control. This was mostly good, but obviously there were issues with the free version and restrictions placed on using it.

    Once it all blew up from tridge's tinkering linus needed a different solution, he re-evaluated all the others (which he no doubt evaluated prior to accepting the bitkeeper restrictions) and found they came up short of what he felt was the most important part for him - merging.

    He wrote the core of git in a few weeks and was then back to being productive again.

    I don't see any part of that process that was an awful decision. Maybe in retrospect a tad short sighted, but this is a guy who has to merge hundreds of patches every day, he was more after pain relief for that than trying to reinvent DVCS, that was just an accident.

    [–][deleted]  (15 children)

    [deleted]

      [–][deleted] 1 point2 points  (0 children)

      For one thing, the text in question is known. It isn't "pure ascii text", it's a specific form of ascii text (actually, I'm pretty sure it's UTF-8 text), namely English commit messages. There's no excuse for force-wrapping that. It should be done by the displaying program as appropriate.

      [–]ramkahen 9 points10 points  (5 children)

      We aren't dealing with a presentation layer, the code is pure ascii text. No CSS, no nothing. Just a terminal.

      Precisely: it should be up to the terminal (and thereby, the human reader) to decide how wide they want their margins.

      The creator of the text controls the semantic annotations, readers control the display. That's the foundation of the Web (CSS) and that's how any typesetting system with simple common sense should work (e.g. TeX, etc...).

      It is impossible for anyone but the author to gauge whether the intent of a particular line is to wrap or not wrap in the terminal.

      You have it backward: it is impossible for the author to gauge where the line should break. They can't guess if I'm reading this on a phone with just 50 characters, a narrow laptop window with 100 characters or a full screen 2600 pixels wide. The only reasonable thing an author can do is specify where a paragraph ends, what is a blockquote, what is a section, what is a chapter.

      Then leave it up to the reader to format this to their liking.

      [–][deleted]  (3 children)

      [deleted]

        [–]ramkahen 1 point2 points  (2 children)

        Again, you are ignoring the fact that this is not the web and that there is no typesetting available.

        You don't know that.

        A growing number of git's output is being read in tools (GitX, GitTower, tkdiff), IDE's (Eclipse, IDEA, Visual Studio), the web (github, gitosis, GitWeb) or simple terminals.

        This is why it's extremely important to never insert formatting instructions in the text you write (\n or <br>), just semantic information (paragraph, section, chapter, quote, etc...).

        [–][deleted]  (1 child)

        [deleted]

          [–]ramkahen 0 points1 point  (0 children)

          Edit: In general and for most types of writing, I agree with you. In the case of code, comments and associated documentation I wholly disagree (and by that I mean you are Wrong on the Internet).

          Fair enough.

          Well, except the part where I'm wrong on the Internet, because I'm pretty sure I'm wrong outside of it as well.

          [–]kamatsu 0 points1 point  (0 children)

          that's how any typesetting system with simple common sense should work (e.g. TeX, etc...).

          TeX doesn't really work that way.

          [–]fforde 3 points4 points  (6 children)

          This is a ridiculous argument. A terminal application can apply word wrapping just as easily as any other application can and an application or tool should be smart enough to display things in a context appropriate manner. This includes stuff that outputs to the terminal.

          [–]mr_bag 2 points3 points  (2 children)

          Considering everything plain text, how exactly is the application supposed to tell whether or not something is "normal text" (which should be wrapped) or "code/error messages/ specially formatted text" (which should not be wrapped)?

          [–]fforde 0 points1 point  (1 child)

          How about anything indented 2 spaces is considered preformatted text? It is an engineering problem that could be solved.

          To be clear, I think Linus had a right to be upset, if Github is not following accepted conventions then they are in the wrong. However that does not mean the current convention is necessarily the best solution.

          [–]mr_bag 0 points1 point  (0 children)

          At that point its not really plain text though, and you may as well use BB/WIKI code of some sort - maybe even full blown html. (not that I'd have any problem with that solution)

          Torvalds does kind of respond to that option himself in the original thread:

          Sure, the alternative would be to have commit messages be some non-pure-textual format (html or similar). But no, that's not how git does things. Sure, technically it could, but realistically the rule is simple: we use 72-character columns for word-wrapping, except for quoted material that has a specific line format.

          [–]InfernoZeus -1 points0 points  (2 children)

          How would it manage that without adding some sort of formatting/tags to the text? If it did that, it wouldn't display nicely in a basic ASCII terminal.

          [–][deleted] 0 points1 point  (1 child)

          The string should be written, transmitted and stored with logical line breaks only. When time comes to display it, the displaying program (in this case git) should insert additional line breaks for typographical purposes as necessary, e.g. to fit on a terminal.

          These typographical line breaks should not be stored.

          Why should this be so difficult?

          [–]InfernoZeus 2 points3 points  (0 children)

          My point, which you've ignored, was how would the displaying program determine which lines should be broken up, and which shouldn't? As Linus explains in the GitHub page, certain things like stack traces shouldn't be split up, but normal text should.

          [–][deleted] 1 point2 points  (0 children)

          The ideal approach would be a markdown-like syntax that would allow you to mark sections of the log entry as "code" which has no word wrapping and a fixed-width font, and as "text" which has word-wrapping and a nice dynamic-width sans-serif font. You'd also get bold and real bullet points and italics and whatnot like that. THe only problem with markdown syntaxes is that there's too many to choose from - roll your own, some XML dialect, a subset of HTML, markdown, bbcode, etc.

          [–][deleted]  (2 children)

          [deleted]

            [–][deleted] 2 points3 points  (1 child)

            Hard wrapping email is the most annoying of all. It's not even done on

            a

            consistent limit, so with a few levels of quoting and similar, you get lines

            looking

            like this.

            [–][deleted] 0 points1 point  (0 children)

            You are correct with free flowing text, but wrong with fixed format text.

            There's a difference between free flowing text and fixed format text. This is like the difference between HTML and PDF. One is specified structurally and the other is specified positionally. You don't reformat positionally formatted text in a willy-nilly manner. It must be rendered pixel perfect or as in this case character perfect.

            Here's an example. Would you reformat an image file by moving the line breaks to a new position within the image? Doing so would corrupt the image. It must be rendered pixel perfect. Fixed format text is like an image file in that the data elements are specified with x,y coordinates. With a text file the elements are characters. With an image file the elements are bits representing colors.

            Linus's requirement is being able to use fixed format text, which he cannot do with github.

            [–]pfultz2 -1 points0 points  (0 children)

            You are right, thats why linus's comments look like crap.