Hacker News Reader

Comment by nailer | Hacker News Reader

(you don't need to link to RFC2822 section 2.1.1, it's linked to in the article that you just read)

I'm quite familiar with the 78 line break as a Unix user for the last 15 years, but Section 2.1.1 is RFC 2822 should never have been carried forward from RFC 822, where it was originally written decades ago:

- There are many displays less than 78 characters wide.

- There are many displays more than 78 characters wide.

- Most apps that run on displays that are 78 characters wide can happily display paragraphs in their available width.

The IETF is wrong. For that matter, I even wrote a Chrome extension to specifically fix reading IETF papers: https://github.com/mikemaccana/deneckbeard

View on HN

To me the 78 line break is still relevant, not because my displays are small, but because wider texts are less readable.

That's a legitimate concern: 8-12 words per line was tested and found to be optimal some years ago in print, and the web since 2001, where it was called 'snake text' http://www.suck.com/daily/2001/01/15/. However a hard 78 character limit isn't exactly 8-12 characters, and hard broken lines will still look poor on small displays.

Ultimately, email should be content only, and display handled on the display device.

The recipient client's limitations shouldn't limit me as a sender. If I want to include a long code sample, or some concrete poetry, gmail shouldn't step on my toes. I don't mind the current behavior being the default, but it should be settable.

That's fine, just as long as you also recognize the recipient's ability to configure away your code sample and poetic white space entirely.

Configurable pattern heuristics to help me, as a recipient, optimally render text would be much more welcome than any capability that could be provided to me as a sender.

Code and poetry can be formatted with whatever line breaks you want. We're just talking about not putting CRs in the middle of paragraphs.

Really? I thought the article said that lines would be hard-wrapped after 78 characters.

I can send you a very long message, in a paragraph, like this. It has a lot of words, and display is determined by the software running on the display device. Immediately afterwards I can include some code:

  // Do a thing. This a pretty boring example, but it's here to
  // illustrate a point. I've hard wrapped it to fit at some 
  // arbitrary length
  var foo = 'bar'

So, word wrap? This is the same stupid argument that pro-spaces people make in the tabs-vs-spaces argument - that you have to use spaces (or hard line breaks) so that you can force your ideal indent size (or line length) on other people.

Just accept the other people have different preferences, and tabs and soft word-wrapping enables them to use their preference. If you don't then you're being selfish really.

You cannot align things on different lines with soft tabs. If you really need to change the indentation, you could always do it based on spaces (not that I have seen any editors capable of doing it) - again, you will mess up the alignment.

I completely agree with the soft wrapping of emails though.

That is correct, you can't align things on different lines with soft tabs. So don't do it! When using tabs, only use them for semantic indentation, not for alignment. In most cases, to align things: enter a newline character, tab-in the same number of tabs as the previous line, then add spaces to align. This is the one true correct way because it allows anybody to use any size tabs imaginable and still works without breaking alignment.

Unfortunately, the world is full of people who don't understand this, so when tabs are used, they are used incorrectly (for alignment). Therefore, the one truerest way is (unfortunately) spaces for both indentation and for alignment. I've come to accept this non-ideal solution as a consequence of the wonderful but imperfect nature of Humanity.

enter a newline character, tab-in the same number of tabs as the previous line, then add spaces to align.

That method is broken unless we also agree on a tab width, in which case we may as well use spaces anyway.

I suggest you try it. Here is an example file [1]. Try adjusting the tab size: you'll find the arguments are always aligned. I like to set vim's listchars with the UTF-8 light shade and medium shade blocks to make tabs visible. Here are screenshots with ts=4 [2] and with ts=16 [3].

[1] http://sprunge.us/AOGg

[2] http://i5.minus.com/iu14dVi9QRTri.png [3] http://i4.minus.com/itno9LlgJobQD.png

I see the confusion. For aligning function call arguments your strategy works fine. Here are a couple use cases that don't work out so well with tabs (taken from the Jalopy manual [0] to make finding examples easy):

function declaration (most people would accidentally use too many tabs here):

    public void severalParameters(String one, int two, String three,
                                  StringObject four, AnotherObject five) {
        ...
    }

assignments:

    String        text  = "text";
    int           a     = -1;
    History.Entry entry = new History.Entry(text);

Ultimately the problem with mixing spaces and tabs in one document is that programmers are human. Someone will inevitably make a change to the lines you've carefully indented and mess up the whitespace, and someone else will have to go back to fix it in a dummy commit. Having a simple rule that's easy to follow eliminates that source of wasted effort.

[0]: http://jalopy.sourceforge.net/existing/manual.html

The strategy works perfectly fine for those examples.

    	public void severalParameters(String one, int two, String three,
    	                              StringObject four, AnotherObject five) {
    		// No problems here. It's just like my example.
    		// We're two levels of indentation in for these comments.
    		// The argument list continuation was at 1-level indentation with spaces for alignment
    	}

For these assignments, anything to the left is a semantic indentation (tabs), the rest is all alignment (spaces).

    	String        text  = "text";
    	int           a     = -1;
    	History.Entry entry = new History.Entry(text);

Sure, you can make it work. By point is just that you're introducing a burden making people remember which whitespace to use in which context. At that point you're forcing your devs to show non-printable characters in their editor to get it right. You devs are now spending their time checking whitespace instead of writing code, which is lost productivity.

As with any coding standard, the point of the rule is to eliminate such sources of lost productivity.

What things are you aligning on different lines? Are you stuffing spaces between variables and assignment operators "a = 1"?

Don't do that. It looks ugly on my tab-indented, proportional font display.

Usually, it's argument lists that need aligning.

I personally hate aligned assignments. I find it very sloppy. But yes, that is what you would do if you so wanted aligned assignments.

Using only tabs, you cannot do aligned assignments unless you are able to set specific tab stops per line. If you disagree, I can provide an assignment example that breaks tabs. While per-line tab stops might be possible, the overhead of maintaining tab stops vs not using aligned assignments is not worth it.

Reply on news.ycombinator.com