I also use multiple 80-column windows side-by-side, and long lines are
quite unreadable. I have a local emacs key binding to make the window
120 wide temporarily for when I'm working on Simon's code :-) There's
also the issue of having side-by-side diffs in Phabricator being
readable on a laptop screen, for which I think 80 is a reasonable limit.
I think the current level of nagging in Phabricator isn't terrible,
though if we want to make it less annoying I believe it's also possible
to make it an "advice"-level warning, which wouldn't force you to
explain yourself, but it would still appear in the diff.
Cheers
Simon
On 09/11/2015 22:51, Richard Eisenberg wrote:
At both school and at home I can fit 3 80-character buffers side by side, at a
comfortable font size. Going up (even to 85 cols) would mean losing a buffer.
(Or straining my eyes.) Of course I can deal with wrapped lines. But I still
vote for 80 characters as a target, while allowing people wiggle room to miss
this target.
The number 80 is with us for historical reasons, but I know I'm not the only
one who still routinely uses 80-column buffers.
Richard
On Nov 9, 2015, at 5:45 PM, Simon Peyton Jones <[email protected]> wrote:
In my view 80 chars is too short. It was justified in the days of 80-column
CRTs, but that just isn't a restriction any more. I routinely edit in a much
wider window.
Clearly there's a judgement call here. But I'd prefer 120 cols say.
Simon
-----Original Message-----
From: ghc-devs [mailto:[email protected]] On Behalf Of Richard
Eisenberg
Sent: 09 November 2015 21:03
To: ghc-devs Devs <[email protected]>
Subject: too many lines too long
Hi devs,
We seem to be uncommitted to the ideal of 80-character lines. Almost every patch on Phab
I look through has a bunch of "line too long" lint errors. No one seems to do
much about these. And Phab's very very loud indication of a lint error makes reviewing
the code harder.
I like the ideal of 80-character lines. I aim for this ideal in my patches, falling short
sometimes, of course. But I think the current setting of requiring everyone to
"explain" away their overlong lines during `arc diff` and then trying hard to
ignore the lint errors during code review is wrong. And it makes us all inured to more
serious lint errors.
How about this: after `arc diff` is run, it will count the number of overlong
lines before and after the patch. If there are more after, have the last thing
`arc diff` outputs be a stern telling-off of the dev, along the lines of
Before your patch, 15 of the edited lines were over 80 characters.
Now, a whopping 28 of them are. Can't you do better? Please?
Would this be ignored more or followed more? Who knows. But it would sure be
less annoying. :)
What do others think?
Thanks,
Richard
_______________________________________________
ghc-devs mailing list
[email protected]
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
