Patchwork [C++] PR 32614

login
register
mail settings
Submitter Paolo Carlini
Date Oct. 16, 2011, 10:03 a.m.
Message ID <4E9AAC05.1050801@oracle.com>
Download mbox | patch
Permalink /patch/120021/
State New
Headers show

Comments

Paolo Carlini - Oct. 16, 2011, 10:03 a.m.
Hi,

in this simple documentation PR, Tom noticed that we have a (very long 
standing) inconsistency between the default value of -fmessage-length 
for C++ as documented and as implemented: in fact it's 0 in 
cxx-pretty-print.c, like all the other front-ends. At the time of the PR 
people briefly envisage changing the default but the discussion didn't 
go anywhere, I think we can as well do the below, for the time being at 
least, remove the inconsistency.

Ok?

Thanks,
Paolo.

/////////////////////
2011-10-16  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/32614
	* doc/invoke.texi ([Language Independent Options]): Change default
	value of -fmessage-length for C++ to match implementation.
Gabriel Dos Reis - Oct. 16, 2011, 10:28 a.m.
On Sun, Oct 16, 2011 at 5:03 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> in this simple documentation PR, Tom noticed that we have a (very long
> standing) inconsistency between the default value of -fmessage-length for
> C++ as documented and as implemented: in fact it's 0 in cxx-pretty-print.c,
> like all the other front-ends. At the time of the PR people briefly envisage
> changing the default but the discussion didn't go anywhere, I think we can
> as well do the below, for the time being at least, remove the inconsistency.
>
> Ok?

I still think the default for g++ should be 72.  Notice that other
front-ends have
set it to zero because they feared something, unlike the C++ frontend.
Paolo Carlini - Oct. 16, 2011, 10:31 a.m.
On 10/16/2011 12:28 PM, Gabriel Dos Reis wrote:
> On Sun, Oct 16, 2011 at 5:03 AM, Paolo Carlini<paolo.carlini@oracle.com>  wrote:
>> Hi,
>>
>> in this simple documentation PR, Tom noticed that we have a (very long
>> standing) inconsistency between the default value of -fmessage-length for
>> C++ as documented and as implemented: in fact it's 0 in cxx-pretty-print.c,
>> like all the other front-ends. At the time of the PR people briefly envisage
>> changing the default but the discussion didn't go anywhere, I think we can
>> as well do the below, for the time being at least, remove the inconsistency.
>>
>> Ok?
> I still think the default for g++ should be 72.  Notice that other
> front-ends have set it to zero because they feared something, unlike the C++ frontend.
To be clear, I have no strong opinion. But last time Richard Gunther 
strongly disagreed (and now he is a Global Reviewer ;) Thus, just let me 
know guys...

Paolo.
Richard Guenther - Oct. 16, 2011, 10:42 a.m.
On Sun, Oct 16, 2011 at 12:31 PM, Paolo Carlini
<paolo.carlini@oracle.com> wrote:
> On 10/16/2011 12:28 PM, Gabriel Dos Reis wrote:
>>
>> On Sun, Oct 16, 2011 at 5:03 AM, Paolo Carlini<paolo.carlini@oracle.com>
>>  wrote:
>>>
>>> Hi,
>>>
>>> in this simple documentation PR, Tom noticed that we have a (very long
>>> standing) inconsistency between the default value of -fmessage-length for
>>> C++ as documented and as implemented: in fact it's 0 in
>>> cxx-pretty-print.c,
>>> like all the other front-ends. At the time of the PR people briefly
>>> envisage
>>> changing the default but the discussion didn't go anywhere, I think we
>>> can
>>> as well do the below, for the time being at least, remove the
>>> inconsistency.
>>>
>>> Ok?
>>
>> I still think the default for g++ should be 72.  Notice that other
>> front-ends have set it to zero because they feared something, unlike the
>> C++ frontend.
>
> To be clear, I have no strong opinion. But last time Richard Gunther
> strongly disagreed (and now he is a Global Reviewer ;) Thus, just let me
> know guys...

0 is just so much more convenient for consumers and all consumers that
care for line lengths can properly wrap around.  So I don't see a good
reason to have -fmessage-length at all.

Richard.

> Paolo.
>
Gabriel Dos Reis - Oct. 16, 2011, 11:03 a.m.
On Sun, Oct 16, 2011 at 5:42 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Sun, Oct 16, 2011 at 12:31 PM, Paolo Carlini
> <paolo.carlini@oracle.com> wrote:
>> On 10/16/2011 12:28 PM, Gabriel Dos Reis wrote:
>>>
>>> On Sun, Oct 16, 2011 at 5:03 AM, Paolo Carlini<paolo.carlini@oracle.com>
>>>  wrote:
>>>>
>>>> Hi,
>>>>
>>>> in this simple documentation PR, Tom noticed that we have a (very long
>>>> standing) inconsistency between the default value of -fmessage-length for
>>>> C++ as documented and as implemented: in fact it's 0 in
>>>> cxx-pretty-print.c,
>>>> like all the other front-ends. At the time of the PR people briefly
>>>> envisage
>>>> changing the default but the discussion didn't go anywhere, I think we
>>>> can
>>>> as well do the below, for the time being at least, remove the
>>>> inconsistency.
>>>>
>>>> Ok?
>>>
>>> I still think the default for g++ should be 72.  Notice that other
>>> front-ends have set it to zero because they feared something, unlike the
>>> C++ frontend.
>>
>> To be clear, I have no strong opinion. But last time Richard Gunther
>> strongly disagreed (and now he is a Global Reviewer ;) Thus, just let me
>> know guys...
>
> 0 is just so much more convenient for consumers and all consumers that
> care for line lengths can properly wrap around.  So I don't see a good
> reason to have -fmessage-length at all.

This is an argument that should have been made more than a decade ago
and -fmessage-length was *requested* by users who did care about
line length, and implemented for g++.
Richard Guenther - Oct. 17, 2011, 6:44 a.m.
On Sun, Oct 16, 2011 at 1:03 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Sun, Oct 16, 2011 at 5:42 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Sun, Oct 16, 2011 at 12:31 PM, Paolo Carlini
>> <paolo.carlini@oracle.com> wrote:
>>> On 10/16/2011 12:28 PM, Gabriel Dos Reis wrote:
>>>>
>>>> On Sun, Oct 16, 2011 at 5:03 AM, Paolo Carlini<paolo.carlini@oracle.com>
>>>>  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> in this simple documentation PR, Tom noticed that we have a (very long
>>>>> standing) inconsistency between the default value of -fmessage-length for
>>>>> C++ as documented and as implemented: in fact it's 0 in
>>>>> cxx-pretty-print.c,
>>>>> like all the other front-ends. At the time of the PR people briefly
>>>>> envisage
>>>>> changing the default but the discussion didn't go anywhere, I think we
>>>>> can
>>>>> as well do the below, for the time being at least, remove the
>>>>> inconsistency.
>>>>>
>>>>> Ok?
>>>>
>>>> I still think the default for g++ should be 72.  Notice that other
>>>> front-ends have set it to zero because they feared something, unlike the
>>>> C++ frontend.
>>>
>>> To be clear, I have no strong opinion. But last time Richard Gunther
>>> strongly disagreed (and now he is a Global Reviewer ;) Thus, just let me
>>> know guys...
>>
>> 0 is just so much more convenient for consumers and all consumers that
>> care for line lengths can properly wrap around.  So I don't see a good
>> reason to have -fmessage-length at all.
>
> This is an argument that should have been made more than a decade ago
> and -fmessage-length was *requested* by users who did care about
> line length, and implemented for g++.

I wasn't around at that time, so sorry for not raising my opinion earlier ;)

Richard.
Paolo Carlini - Oct. 17, 2011, 9:42 a.m.
FWIW, I still believe that tweaking the documentation to match the long 
standing reality, would be a small improvement. I'm not going to further 
insist, anyway.

Paolo.
Richard Guenther - Oct. 17, 2011, 10:25 a.m.
On Mon, Oct 17, 2011 at 11:42 AM, Paolo Carlini
<paolo.carlini@oracle.com> wrote:
> FWIW, I still believe that tweaking the documentation to match the long
> standing reality, would be a small improvement. I'm not going to further
> insist, anyway.

The original patch is ok.

Thanks,
Richard.

> Paolo.
>
Gabriel Dos Reis - Oct. 17, 2011, 10:26 a.m.
On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> FWIW, I still believe that tweaking the documentation to match the long
> standing reality, would be a small improvement. I'm not going to further
> insist, anyway.

It isn't improvement.
The improvement would be to restore the documented default.
Gabriel Dos Reis - Oct. 17, 2011, 10:26 a.m.
On Mon, Oct 17, 2011 at 5:25 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Mon, Oct 17, 2011 at 11:42 AM, Paolo Carlini
> <paolo.carlini@oracle.com> wrote:
>> FWIW, I still believe that tweaking the documentation to match the long
>> standing reality, would be a small improvement. I'm not going to further
>> insist, anyway.
>
> The original patch is ok.
Richard, I don't think it is.
Richard Guenther - Oct. 17, 2011, 10:28 a.m.
On Mon, Oct 17, 2011 at 12:26 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>> FWIW, I still believe that tweaking the documentation to match the long
>> standing reality, would be a small improvement. I'm not going to further
>> insist, anyway.
>
> It isn't improvement.
> The improvement would be to restore the documented default.

I disagree.  Well, both would be an improvement.  Restoring the documented
default would be a move in the wrong direction though.  Why have different
defaults for different languages anyway?  How long has the "new" default
be in effect?

Richard.
Gabriel Dos Reis - Oct. 17, 2011, 10:30 a.m.
On Mon, Oct 17, 2011 at 5:28 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Mon, Oct 17, 2011 at 12:26 PM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>>> FWIW, I still believe that tweaking the documentation to match the long
>>> standing reality, would be a small improvement. I'm not going to further
>>> insist, anyway.
>>
>> It isn't improvement.
>> The improvement would be to restore the documented default.
>
> I disagree.  Well, both would be an improvement.  Restoring the documented
> default would be a move in the wrong direction though.  Why have different
> defaults for different languages anyway?

That is a question for the other front-ends which are not obliged to pick
just about anything implemented for g++.

>  How long has the "new" default be in effect?
>
> Richard.
>
Paolo Carlini - Oct. 17, 2011, 10:38 a.m.
On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
> On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini<paolo.carlini@oracle.com>  wrote:
>> FWIW, I still believe that tweaking the documentation to match the long
>> standing reality, would be a small improvement. I'm not going to further
>> insist, anyway.
> It isn't improvement.
> The improvement would be to restore the documented default.
Well either my English is even weaker than I thought, or "restoring" 
doesn't apply here: the line of code at  issue, 
pp_set_line_maximum_length (pp, 0), has been added by Gaby in Rev 70777, 
and nothing similar with 72 as second argument existed before.

Paolo.
Richard Guenther - Oct. 17, 2011, 10:53 a.m.
On Mon, 17 Oct 2011, Paolo Carlini wrote:

> On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
> > On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini<paolo.carlini@oracle.com>
> > wrote:
> > > FWIW, I still believe that tweaking the documentation to match the long
> > > standing reality, would be a small improvement. I'm not going to further
> > > insist, anyway.
> > It isn't improvement.
> > The improvement would be to restore the documented default.
> Well either my English is even weaker than I thought, or "restoring" doesn't
> apply here: the line of code at  issue, pp_set_line_maximum_length (pp, 0),
> has been added by Gaby in Rev 70777, and nothing similar with 72 as second
> argument existed before.

Thus clearly the documentation is wrong ;)  So, I'll approve the patch
for the release branches (where we don't want to change the default).
We can bikeshed a bit more for trunk.

Richard.
Gabriel Dos Reis - Oct. 17, 2011, 10:56 a.m.
On Mon, Oct 17, 2011 at 5:53 AM, Richard Guenther <rguenther@suse.de> wrote:
> On Mon, 17 Oct 2011, Paolo Carlini wrote:
>
>> On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
>> > On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini<paolo.carlini@oracle.com>
>> > wrote:
>> > > FWIW, I still believe that tweaking the documentation to match the long
>> > > standing reality, would be a small improvement. I'm not going to further
>> > > insist, anyway.
>> > It isn't improvement.
>> > The improvement would be to restore the documented default.
>> Well either my English is even weaker than I thought, or "restoring" doesn't
>> apply here: the line of code at  issue, pp_set_line_maximum_length (pp, 0),
>> has been added by Gaby in Rev 70777, and nothing similar with 72 as second
>> argument existed before.
>
> Thus clearly the documentation is wrong ;)

;-)
Not necessarily.  Paolo does not say why that line was added.
I don't remember adding that line to change the default.


> So, I'll approve the patch
> for the release branches (where we don't want to change the default).
> We can bikeshed a bit more for trunk.
>
> Richard.
>
Richard Guenther - Oct. 17, 2011, 11:08 a.m.
On Mon, 17 Oct 2011, Gabriel Dos Reis wrote:

> On Mon, Oct 17, 2011 at 5:53 AM, Richard Guenther <rguenther@suse.de> wrote:
> > On Mon, 17 Oct 2011, Paolo Carlini wrote:
> >
> >> On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
> >> > On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini<paolo.carlini@oracle.com>
> >> > wrote:
> >> > > FWIW, I still believe that tweaking the documentation to match the long
> >> > > standing reality, would be a small improvement. I'm not going to further
> >> > > insist, anyway.
> >> > It isn't improvement.
> >> > The improvement would be to restore the documented default.
> >> Well either my English is even weaker than I thought, or "restoring" doesn't
> >> apply here: the line of code at  issue, pp_set_line_maximum_length (pp, 0),
> >> has been added by Gaby in Rev 70777, and nothing similar with 72 as second
> >> argument existed before.
> >
> > Thus clearly the documentation is wrong ;)
> 
> ;-)
> Not necessarily.  Paolo does not say why that line was added.
> I don't remember adding that line to change the default.

The initial patch, split between rev. 31343 and 31999 indeed added
 
+  /* Enable automatic line wrapping by default */
+  set_message_length (72);

to C++ lang_decode_option.  Later it got appearantly lost somehow,
probably during some of the Great Option Reorgs.

I still think automatic wrapping (at 72 columns!?  A terminal
is 80x24!) should not be done by default.  You probably will break
a lot of existing scripts that assume the default of zero.

Richard.
Gabriel Dos Reis - Oct. 17, 2011, 11:08 a.m.
On Mon, Oct 17, 2011 at 5:38 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini<paolo.carlini@oracle.com>
>>  wrote:
>>>
>>> FWIW, I still believe that tweaking the documentation to match the long
>>> standing reality, would be a small improvement. I'm not going to further
>>> insist, anyway.
>>
>> It isn't improvement.
>> The improvement would be to restore the documented default.
>
> Well either my English is even weaker than I thought, or "restoring" doesn't
> apply here: the line of code at  issue, pp_set_line_maximum_length (pp, 0),
> has been added by Gaby in Rev 70777, and nothing similar with 72 as second
> argument existed before.

Looking at the changset, now I remember:  That line was part of a change set
that was improving the *C* pretty-printer I added earlier and to
maximize  sharing
more cose between the C and C++ pretty printers.  The zero length was added
as an attempt to respect the *C* front-end desire not have line wrapping.
Richard talked about other front-ends, but at the time, there was only
two front-ends
who were using the pretty printers: C and C++.  The C front-end was adopting
bits of the C++ front-end.  Every other front-end were doing whatever
they wanted.
It wasn't like there was a bit debate with other front-ends to decide
what the default
should be for all.
Paolo Carlini - Oct. 17, 2011, 11:09 a.m.
On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
>> Thus clearly the documentation is wrong ;)
> ;-)
> Not necessarily.  Paolo does not say why that line was added.
> I don't remember adding that line to change the default.
Indeed, as far as I can see, you added that line while *preserving* the 
existing behavior and preparing the C++ variant of the pretty_print 
machinery. Thus, AFAICS, 72 never existed anywhere and, strictly 
speaking, there is nothing to *restore*.

But I may be wrong, I don't own viewcvs, I just quickly queried it.

Paolo.
Gabriel Dos Reis - Oct. 17, 2011, 11:14 a.m.
On Mon, Oct 17, 2011 at 6:08 AM, Richard Guenther <rguenther@suse.de> wrote:

> The initial patch, split between rev. 31343 and 31999 indeed added

Thanks for helping tracking history.

> +  /* Enable automatic line wrapping by default */
> +  set_message_length (72);
>
> to C++ lang_decode_option.  Later it got appearantly lost somehow,
> probably during some of the Great Option Reorgs.

Yes, most likely.

>
> I still think automatic wrapping (at 72 columns!?  A terminal
> is 80x24!) should not be done by default.

The choice of 72 at the time was based on the 80 of the terminal
and Emacs guidelines.   The requests I have  heared most vocally was to
increase the length of line, not to suppress the wrapping by default.

> You probably will break
> a lot of existing scripts that assume the default of zero.
>
> Richard.
Paolo Carlini - Oct. 17, 2011, 11:14 a.m.
On 10/17/2011 01:08 PM, Richard Guenther wrote:
> The initial patch, split between rev. 31343 and 31999 indeed added
>
> +  /* Enable automatic line wrapping by default */
> +  set_message_length (72);
>
> to C++ lang_decode_option.  Later it got appearantly lost somehow,
> probably during some of the Great Option Reorgs.
Wow, 31343, I didn't look back so much. Now the issue is whether, after 
*so* many years with 0, people would *really* consider seeing the 
default changed to 72, at variance with C and all the other front-ends. 
I seriously doubt it. Do we have strong evidence of that? For example, 
is there something similar in other C++ front-end?

Paolo.
Gabriel Dos Reis - Oct. 17, 2011, 11:16 a.m.
On Mon, Oct 17, 2011 at 6:09 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
>>>
>>> Thus clearly the documentation is wrong ;)
>>
>> ;-)
>> Not necessarily.  Paolo does not say why that line was added.
>> I don't remember adding that line to change the default.
>
> Indeed, as far as I can see, you added that line while *preserving* the
> existing behavior and preparing the C++ variant of the pretty_print
> machinery. Thus, AFAICS, 72 never existed anywhere and, strictly speaking,
> there is nothing to *restore*.

I do not know what you mean by "there is nothing to restore".
Look at the other mail by Richard.  The C pretty-printer *post*-dated
the C++ pretty printer.

>
> But I may be wrong, I don't own viewcvs, I just quickly queried it.
>
> Paolo.
>
Paolo Carlini - Oct. 17, 2011, 11:19 a.m.
On 10/17/2011 01:16 PM, Gabriel Dos Reis wrote:
> On Mon, Oct 17, 2011 at 6:09 AM, Paolo Carlini<paolo.carlini@oracle.com>  wrote:
>> On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
>>>> Thus clearly the documentation is wrong ;)
>>> ;-)
>>> Not necessarily.  Paolo does not say why that line was added.
>>> I don't remember adding that line to change the default.
>> Indeed, as far as I can see, you added that line while *preserving* the
>> existing behavior and preparing the C++ variant of the pretty_print
>> machinery. Thus, AFAICS, 72 never existed anywhere and, strictly speaking,
>> there is nothing to *restore*.
> I do not know what you mean by "there is nothing to restore".
> Look at the other mail by Richard.  The C pretty-printer *post*-dated
> the C++ pretty printer.
Hey, I don't own viewcvs, of svn, for that matter, you could also dare 
to help a bit with this crazy archeological task, can't you?!? I looked 
back only untile 70777, and that point and a bit earlier there where 
already no 72s around, thus, right *nothing to restore*. Now we are 
learning that *even earlier* we had a 72. Fine. Now, after so many 
years, are we ****really**** sure that our users would consider an 
*improvement* a 72? I'm honestly not sure at all. Again, what the best 
C++ front-ends around do, by default? I'm sincerely curious.

Paolo.
Gabriel Dos Reis - Oct. 17, 2011, 11:24 a.m.
On Mon, Oct 17, 2011 at 6:14 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 10/17/2011 01:08 PM, Richard Guenther wrote:
>>
>> The initial patch, split between rev. 31343 and 31999 indeed added
>>
>> +  /* Enable automatic line wrapping by default */
>> +  set_message_length (72);
>>
>> to C++ lang_decode_option.  Later it got appearantly lost somehow,
>> probably during some of the Great Option Reorgs.
>
> Wow, 31343, I didn't look back so much.

I never understood why you doubted that the default was 72
way before I added the C pretty printer.  I can understand you
don't like it; but that should not involve doubting the facts.

> Now the issue is whether, after *so*
> many years with 0, people would *really* consider seeing the default changed
> to 72, at variance with C and all the other front-ends.

Again this argument is making a sort of revisionism.
The 72 default was added to g++, and other front-ends (in reality
at the time, only C could be affected) decided not to.  Over the years, we
have moved to share more and more codes with other front-ends.
The fact that other front-ends have been using more and more of the
code that was designed for g++ should not be argument to change the
default for g++.  It should be other reasons.

> I seriously doubt
> it. Do we have strong evidence of that? For example, is there something
> similar in other C++ front-end?
>
> Paolo.
>
Paolo Carlini - Oct. 17, 2011, 11:26 a.m.
On 10/17/2011 01:24 PM, Gabriel Dos Reis wrote:
> Again this argument is making a sort of revisionism. The 72 default 
> was added to g++, and other front-ends (in reality at the time, only C 
> could be affected) decided not to. Over the years, we have moved to 
> share more and more codes with other front-ends. The fact that other 
> front-ends have been using more and more of the code that was designed 
> for g++ should not be argument to change the default for g++. It 
> should be other reasons. 
At this point, after something like 10 years, I think we badly need 
other reasons to change the C++ default. You are arguing as if we just 
inadvertently changed the C++ default yesterday. If I were a C++ 
front-end maintainer today, I would **strongly** oppose any change to 72 
not strongly motivated at least by a comparison with other high quality 
front-ends and some feedback from the users asking a different default. 
Do we have any of the latter?

Paolo.
Richard Guenther - Oct. 17, 2011, 11:29 a.m.
On Mon, 17 Oct 2011, Gabriel Dos Reis wrote:

> On Mon, Oct 17, 2011 at 6:08 AM, Richard Guenther <rguenther@suse.de> wrote:
> 
> > The initial patch, split between rev. 31343 and 31999 indeed added
> 
> Thanks for helping tracking history.
> 
> > +  /* Enable automatic line wrapping by default */
> > +  set_message_length (72);
> >
> > to C++ lang_decode_option.  Later it got appearantly lost somehow,
> > probably during some of the Great Option Reorgs.
> 
> Yes, most likely.
> 
> >
> > I still think automatic wrapping (at 72 columns!?  A terminal
> > is 80x24!) should not be done by default.
> 
> The choice of 72 at the time was based on the 80 of the terminal
> and Emacs guidelines.

I see (and yes, editors probably do not break lines by default - but
my terminals do, and I usually enlarge them to be able to decipher
C++ diagnostics).  I still think that not breaking existing consumers
is more important than to restore something that hasn't been in
effect for years.

Oh, and yes, making documentation match reality is an improvement.

Let's wait for Jason to break the tie.

Richard.
Gabriel Dos Reis - Oct. 17, 2011, 11:29 a.m.
On Mon, Oct 17, 2011 at 6:19 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 10/17/2011 01:16 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 17, 2011 at 6:09 AM, Paolo Carlini<paolo.carlini@oracle.com>
>>  wrote:
>>>
>>> On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
>>>>>
>>>>> Thus clearly the documentation is wrong ;)
>>>>
>>>> ;-)
>>>> Not necessarily.  Paolo does not say why that line was added.
>>>> I don't remember adding that line to change the default.
>>>
>>> Indeed, as far as I can see, you added that line while *preserving* the
>>> existing behavior and preparing the C++ variant of the pretty_print
>>> machinery. Thus, AFAICS, 72 never existed anywhere and, strictly
>>> speaking,
>>> there is nothing to *restore*.
>>
>> I do not know what you mean by "there is nothing to restore".
>> Look at the other mail by Richard.  The C pretty-printer *post*-dated
>> the C++ pretty printer.
>
> Hey, I don't own viewcvs, of svn, for that matter, you could also dare to
> help a bit with this crazy archeological task, can't you?!?

Let's not be quick to judgment and throw more rocks before we get all
the facts. Please understand that I have been helping
and looking at past changesets and present history. I appreciate that Richard
did not think I was just be delusional and helped going back further.
 I can help by presenting history.  It is not my fault when you choose
to doubt or ignore.
That isn't under my control.
Gabriel Dos Reis - Oct. 17, 2011, 11:35 a.m.
On Mon, Oct 17, 2011 at 6:29 AM, Richard Guenther <rguenther@suse.de> wrote:
> On Mon, 17 Oct 2011, Gabriel Dos Reis wrote:
>
>> On Mon, Oct 17, 2011 at 6:08 AM, Richard Guenther <rguenther@suse.de> wrote:
>>
>> > The initial patch, split between rev. 31343 and 31999 indeed added
>>
>> Thanks for helping tracking history.
>>
>> > +  /* Enable automatic line wrapping by default */
>> > +  set_message_length (72);
>> >
>> > to C++ lang_decode_option.  Later it got appearantly lost somehow,
>> > probably during some of the Great Option Reorgs.
>>
>> Yes, most likely.
>>
>> >
>> > I still think automatic wrapping (at 72 columns!?  A terminal
>> > is 80x24!) should not be done by default.
>>
>> The choice of 72 at the time was based on the 80 of the terminal
>> and Emacs guidelines.
>
> I see (and yes, editors probably do not break lines by default - but
> my terminals do, and I usually enlarge them to be able to decipher
> C++ diagnostics).

These days, it is common for terminals to have line wrap.  At the time,
it wasn't common.  Another suggestion I have heard when the line break
was introduced, was to do it based on the characteristics of the output
stream -- for example, adding colors (hello Benjamin!) which I believe
SuSE added, and which demands testing the output stream. Another
suggestion was people wanted to look at COLUMNS to automatically
set the line length -- this comes from people using more than 80.
-fmessage-length=0 had an internal necessity: the testsuites.  I modified
the testsuite framework to automatically set the length to 0.

>   I still think that not breaking existing consumers
> is more important than to restore something that hasn't been in
> effect for years.
>
> Oh, and yes, making documentation match reality is an improvement.
>
> Let's wait for Jason to break the tie.
>
> Richard.
Gabriel Dos Reis - Oct. 17, 2011, 11:44 a.m.
On Mon, Oct 17, 2011 at 6:26 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> I would **strongly** oppose any change to 72 not strongly
> motivated at least by a comparison with other high quality front-ends

I love it when you make arguments like this.  It makes me smile, and
I like smiling when I just get off bed :-)

Just another fact: the decision of line wrapping was based in comparison
to what another high quality front-end was doing.  It wasn't a design decision
made out of tin air.

I suspect you do not even agree with the fact that the change was accidental,
not intended.  Yet, I bet you will shortly tell me that I am not helping with
giving history behind the changes.
Paolo Carlini - Oct. 17, 2011, 11:48 a.m.
On 10/17/2011 01:44 PM, Gabriel Dos Reis wrote:
> On Mon, Oct 17, 2011 at 6:26 AM, Paolo Carlini<paolo.carlini@oracle.com>  wrote:
>> I would **strongly** oppose any change to 72 not strongly
>> motivated at least by a comparison with other high quality front-ends
> I love it when you make arguments like this.  It makes me smile, and
> I like smiling when I just get off bed :-)
I don't see why. In any case please consider also the second half of 
that phrase, the users, like Richard for example, or me. And please help 
re-assessing the situation wrt the other front-ends *today* not in the 
stone age.

Paolo.
Gabriel Dos Reis - Oct. 17, 2011, 11:59 a.m.
On Mon, Oct 17, 2011 at 6:48 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 10/17/2011 01:44 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 17, 2011 at 6:26 AM, Paolo Carlini<paolo.carlini@oracle.com>
>>  wrote:
>>>
>>> I would **strongly** oppose any change to 72 not strongly
>>> motivated at least by a comparison with other high quality front-ends
>>
>> I love it when you make arguments like this.  It makes me smile, and
>> I like smiling when I just get off bed :-)
>
> I don't see why.

If I reveal that then I may very well lose a valuable source of
smile inducer :-)

>  In any case please consider also the second half of that
> phrase, the users, like Richard for example, or me.

you should consider I did -- just like I give you the benefits
of doubt (for example, I do not assume you want to be rude
for entertainment purposes).

> And please help
> re-assessing the situation wrt the other front-ends *today* not in the stone
> age.
>
> Paolo.
>
Jason Merrill - Oct. 17, 2011, 5:31 p.m.
On 10/17/2011 07:48 AM, Paolo Carlini wrote:
> And please help
> re-assessing the situation wrt the other front-ends *today* not in the
> stone age.

EDG always wraps diagnostics at ~80 columns.

clang wraps diagnostics at $COLUMNS when stderr is going to a terminal, 
and doesn't wrap otherwise.

The clang behavior seems like the right way to go.

Jason
Paolo Carlini - Oct. 17, 2011, 5:33 p.m.
On 10/17/2011 07:31 PM, Jason Merrill wrote:
> clang wraps diagnostics at $COLUMNS when stderr is going to a 
> terminal, and doesn't wrap otherwise.
>
> The clang behavior seems like the right way to go.
Thanks Jason. I'll see how to implement this.

Paolo.
Gabriel Dos Reis - Oct. 17, 2011, 6:13 p.m.
On Mon, Oct 17, 2011 at 12:31 PM, Jason Merrill <jason@redhat.com> wrote:
> On 10/17/2011 07:48 AM, Paolo Carlini wrote:
>>
>> And please help
>> re-assessing the situation wrt the other front-ends *today* not in the
>> stone age.
>
> EDG always wraps diagnostics at ~80 columns.

I did not mention the name of the compiler before.  Yes EDG's before
was the model for my original implementation.  The choice of 72 instead
of 80 was because of Emacs guidelines -- which at the time I was told
superseded everything :-)

> clang wraps diagnostics at $COLUMNS when stderr is going to a terminal, and
> doesn't wrap otherwise.
>
> The clang behavior seems like the right way to go.

Looking at COLUMNS was suggested in the past on several occasions.
I am OK with it.

Patch

Index: doc/invoke.texi
===================================================================
--- doc/invoke.texi	(revision 180048)
+++ doc/invoke.texi	(working copy)
@@ -2802,10 +2802,9 @@  the remaining front ends would be able to digest t
 @item -fmessage-length=@var{n}
 @opindex fmessage-length
 Try to format error messages so that they fit on lines of about @var{n}
-characters.  The default is 72 characters for @command{g++} and 0 for the rest of
-the front ends supported by GCC@.  If @var{n} is zero, then no
-line-wrapping will be done; each error message will appear on a single
-line.
+characters.  The default is 0 for all the front ends supported by
+GCC@.  If @var{n} is zero, then no line-wrapping will be done; each
+error message will appear on a single line.
 
 @opindex fdiagnostics-show-location
 @item -fdiagnostics-show-location=once