| Message ID | 4E9AAC05.1050801@oracle.com |
|---|---|
| State | New |
| Headers | show |
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.
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.
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. >
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++.
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.
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.
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. >
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.
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.
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.
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. >
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.
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.
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. >
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.
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.
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.
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.
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.
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. >
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.
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. >
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.
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.
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.
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.
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.
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.
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. >
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
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.
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.
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