On 29 Aug 2019 01:08, Ben Bucksch wrote:

Yes, please, don't compress it down to 80 chars from the TTY days of the
1980ies :-( - I'd go for at least 100 chars.

I think we want to use the same rules as mozilla-central, and they use
80ch, just like Thunderbird has always used. You'd have major problems
otherwise especially comparing/maintaining semi-forked files that would
have to look totally different just because they were copied.

It looks like we have pretty good unification coming now, basically
removing special formatting rules for all Thunderbird code, including
Lightning which has been different.

 -Magnus

On 29-08-2019 02:08, Ben Bucksch wrote:

On 29 Aug 2019 09:01, Magnus Melin wrote:

There are very few "semi-forked" files, mostly in the area of
preferences and the about:* pages.

If you really need to compare, you can format the M-C page to C-C
standards first.

We have many lines exceeding 80 chars in JS code, so there well be a lot
of unnecessary churn to reach a design of the TTY era of the 1980s.

Hands up who is still using vi in a terminal window ;-)

Jörg.

I won't go into debate on why each setting is useful or not.

It's all about consistency. If you pick and choose, you don't get that.

 -Magnus

On 29-08-2019 11:51, Jörg Knobloch wrote:

I'd prefer 100-character lines over consistency with m-c.

GL

On 29/08/19 20:58, Magnus Melin wrote:

On 8/29/19 10:51 AM, Jörg Knobloch wrote:

o/

(I do prefer 100ch though, this fits comfortably so that I can view two
files next to each other)

The flexibility is on prettier's end afaik. Here is a note on print
width and why they use 80ch:

https://prettier.io/docs/en/options.html#print-width

Philipp

On 29 Aug 2019 11:01, Philipp Kewisch wrote:

Looks like so far we had a few votes for 100 chars, even from a vi user ;-)

I read the linked article, well, I'm not convinced really. Long lines
happen due to indentation, not because there is so much code on one line.

We'd really need to see some formatting examples to compare to see
whether the code would end up "overly compact". Maybe that's really the
case.

Jörg.

On 8/28/19 7:08 PM, Ben Bucksch wrote:

Well, Prettier does not work that way.  If you tell it lines should be
100 or 120 or whatever, it will format the code to use that line width,
no more, and also no less.  That's how it meets its design goal of
consistency.  For example:

https://prettier.io/playground/#N4Igxg9gdgLgprEAuEAdKBLAZgAgBTRwA0OMA7hCTABYBOcxOWEArrSejl0xgG6MBnDAA8SAuPygk4GAObUYJTFEadu8KTjgAbCQipkd-KtQy14CAJQ5ga+jDZQmAQ23iA3OgC+6dL2e0OMI4ALw2OIQGlKR0DCTMbERqWHyCImJ6mjLyijjKqk6k+lq6kgZGcN7uIEQgEAAOMBjQAsigAbQQZAAKAQitKM68EBgAJjUgAEa0zmAA1nAwAMr1sxhQssgwtCzEIAoAttoA6qbwAqtgcEv9GE28dwCeyOACrbXr4ubdM7IHzsgsK5xLUAFYCYQAIRm80WS2cBzgABl1nBAcC9uDhEt1rJdABFFgQeDotx7Va0L4vSbOSaPbTQCb1WjrGDHMY0ZAARgADDzasyIOJjjN6i9mXAvvwJgBHInwH4NAYgZwCAC0Kjgoy1E3ocrMcB+zj+AKQQLJtXEBwwWx2eyEGwJ8rRZoxtRgtPZo05SAATO6ZhhtLiAMIQA7-F5QQgTFjiAAqtIG5vEXi8QA

Or if that doesn't work, paste the following code here:

https://prettier.io/playground/

and set it to 100 character line width in the options.

if (one, two, three, four,
    five, six, seven, eight, nine,
    ten, eleven, twelve, thirteen) {
  return false;
}

var x = {
  one, two, three, four,
  five, six, seven, eight, nine,
  ten, eleven, twelve, thirteen
};

The code is reformatted to use the full line width.

What I'm saying is Prettier offers auto-formatting but not the kind of
customizability you want, and the auto-formatting is worth it.  That
means developers will need to be flexible about their preferences, as
they are flexible whenever there is disagreement among developers about
the best code style.

Well, I'm afraid that is simply not the case.  As I mentioned before,
for better or worse, Prettier is not designed to be configurable in that
way.  See: https://prettier.io/docs/en/why-prettier.html  and
https://prettier.io/docs/en/option-philosophy.html

It has an escape hatch with |// prettier-ignore| comments to allow for
exceptional cases.

I know we could have a long discussion with lots of views shared on code
style.  You've offered some strong arguments for yours here.  We might
even reach a consensus where everyone is happy. But since we want the
benefits of auto-formatting, we will need to work with the tool that
offers it.

(More in another reply.)

-Paul

Hi all,

Kindly allow me to express some frustration.  I really wish we had had
this discussion about line width sooner than the day that we planned to
start implementing the changes.  Looks like I should have sent the email
sooner to get the ball rolling, knowing how debates on such things take
time.  Hindsight is 20/20, as they say.

Some procedural questions now in my mind:

Can we reach a consensus decision on line width involving everyone on
the team that may want to weigh in, while leaving enough time to do the
work and let reviewers review the work, in order to land the changes
before the merge on Monday?

Should we delay this work 6 weeks until just before the next merge (and
beta release) in order to have more time for discussion to reach a
consensus decision?

the case.

An easy way to do such a comparison is to cut and paste the contents of
a JS file from the TB code base into the Prettier sandbox here:
https://prettier.io/playground/  and then change the --print-width
option back and forth between 100 and 80.

-Paul