From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16122 invoked by alias); 13 Apr 2012 06:03:31 -0000 Received: (qmail 16106 invoked by uid 22791); 13 Apr 2012 06:03:28 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Apr 2012 06:03:14 +0000 Received: from sunsite.mff.cuni.cz (localhost [127.0.0.1]) by sunsite.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id q3D63DZC006094; Fri, 13 Apr 2012 08:03:13 +0200 Received: (from jj@localhost) by sunsite.mff.cuni.cz (8.14.5/8.14.5/Submit) id q3D63Cbx006093; Fri, 13 Apr 2012 08:03:12 +0200 Date: Fri, 13 Apr 2012 06:03:00 -0000 From: Jakub Jelinek To: Ian Lance Taylor Cc: Lawrence Crowl , Manuel =?iso-8859-1?B?TPNwZXotSWLh8WV6?= , Gabriel Dos Reis , Jonathan Wakely , gcc Mailing List Subject: Re: Updated GCC vs Clang diagnostics Message-ID: <20120413060312.GN6148@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00559.txt.bz2 On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote: > Lawrence Crowl writes: > > > On 4/12/12, Manuel López-Ibáñez wrote: > >> So given your ideal implementation, if the user-visible result > >> was exactly like the one in Clang, will you be happy with any of > >> the three things: ranges, color and fix-it hints? > > > > There are many issues with color. Does your reader have any > > color deficiencies? Does your software address them? Does the > > system software render colors well? Is color contrast sufficient? > > Is greyscale contrast sufficient? Color is low on my list of > > desirables. > > It would be terrible if an error message could not be understood without > color. But nobody is suggesting that. > > The question at hand is whether color can be used to enhance an error > message that can be understood without color. For example, whether > color can be added to current error messages without any other changes. > > I personally think it would be an excellent idea. Even clang's C++ > error messages can be long. A simple use of color is an excellent way > to draw the eye to the more important parts of the message. If the > color is not available, then it doesn't help, but the error message can > be understood without it. Yeah, I second this. As Manuel said, we should have an option to select never/auto/always coloring, colors must be just visual enhancements of the diagnostics that even when colors are disabled gives all the info that is needed (highlight error/warning/note diagnostic kind keywords, keywords in the source, perhaps types, whatever), we should limit to a very small set of colors, because not so many colors are actually very readable and perhaps make the color sets configurable somehow (things might be different if people use normally black characters on white background or white characters on black background, grep has GREP_COLORS env var here, ls LS_COLORS). Jakub