public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: Thu, 12 Jul 2001 04:06:00 -0000	[thread overview]
Message-ID: <20010712110603.31522.qmail@sourceware.cygnus.com> (raw)

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 12 Jul 2001 13:02:21 +0200

 Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:
 
 > | 1. It breaks existing tools. E.g. Emacs awaits a "<location>:<line>
 > | <error-msg>" format and gets confused by the current behavior
 > 
 > My personnal experience (yes, I write and compile my work under Emacs)
 > doesn't match your report.  It just works fine.
 
 Emacs detects errors only if they have the format described above. The
 wrapped lines are plain text for it and won't be recognized as a part of
 diagnostic. Try to move the mouse over wrapped and unwrapped
 error-messages! The whole unwrapped message will be marked (which helps
 to increase readability), but only the first line of the wrapped one.
 
 Besides the misinterpretation by tools, the wrapped output is more
 difficulty to read by humans also:
 
 - the human brain can surveying grouped data faster than ungrouped
   one. The current wrapping destroys grouping.
 
 - the count of lines per errormessage is increased by a factor of 3 or
   more in most cases where templates are involved. Therefore messages
   belonging together (e.g. naming of possible candidates) can not be
   read at a glance and I have to scroll the compilation-buffer manually.
 
  
 > [... value for -fmessage-length=X ...]
 > We've through that debate over and over in the past.  The default
 > value was what contented the majority which expressed their voices.
 > The exact value is configurable.
 
 I suggest a value of `0'. ;) ... at least if it is not a tty...
 
 
 > [...]
 > If you don't want the fonctionality, the documentation says you can
 > specify -fmessage-length=0
 
 Older gcc do not know this option and will fail to compile. Therefore it
 does not exist a simple way to gain unwrapped messages with gcc.
 
 I think that backward-compatibility should be preserved in this case,
 because line-wrapping offers only a few advantages but has some drawbacks,
 
 
 
 
 
 Enrico


             reply	other threads:[~2001-07-12  4:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-12  4:06 Enrico Scholz [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-07-16 17:06 Enrico Scholz
2001-07-13 20:36 Gabriel Dos Reis
2001-07-13 17:36 Enrico Scholz
2001-07-13 13:56 Enrico Scholz
2001-07-13 13:46 Enrico Scholz
2001-07-13 13:36 Phil Edwards
2001-07-13 13:26 Enrico Scholz
2001-07-12 12:56 Phil Edwards
2001-07-12  5:06 Gabriel Dos Reis
2001-07-12  1:46 Gabriel Dos Reis
2001-07-11 14:56 enrico.scholz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010712110603.31522.qmail@sourceware.cygnus.com \
    --to=enrico.scholz@informatik.tu-chemnitz.de \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).