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
next 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: linkBe 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).