On Fri, Apr 12, 2013 at 12:48:23AM +0200, Tobias Burnus wrote:
> Gabriel Dos Reis wrote:
> >Patch OK.
>
> I am not sure whether I have seen the latest patch, but in the one I
> saw there is a typo in the .texi text:
>
> +only when the stdandard error is a terminal. The forms
>
> "standard"
Fixe
Gabriel Dos Reis wrote:
Patch OK.
I am not sure whether I have seen the latest patch, but in the one I saw
there is a typo in the .texi text:
+only when the stdandard error is a terminal. The forms
"standard"
Thanks for the patch, I think it can be quite useful.
Tobias
PS: Please also u
On Thu, Apr 11, 2013 at 10:26 AM, Jakub Jelinek wrote:
> On Thu, Apr 11, 2013 at 10:20:18AM -0500, Gabriel Dos Reis wrote:
>> On Thu, Apr 11, 2013 at 12:55 AM, Jakub Jelinek wrote:
>> > On Wed, Apr 10, 2013 at 09:04:06PM -0500, Gabriel Dos Reis wrote:
>> >> We might be saying the same thing using
On Thu, Apr 11, 2013 at 10:20:18AM -0500, Gabriel Dos Reis wrote:
> On Thu, Apr 11, 2013 at 12:55 AM, Jakub Jelinek wrote:
> > On Wed, Apr 10, 2013 at 09:04:06PM -0500, Gabriel Dos Reis wrote:
> >> We might be saying the same thing using different languages.
> >>
> >> I was the %r/%R markers are w
On Thu, Apr 11, 2013 at 12:55 AM, Jakub Jelinek wrote:
> On Wed, Apr 10, 2013 at 09:04:06PM -0500, Gabriel Dos Reis wrote:
>> We might be saying the same thing using different languages.
>>
>> I was the %r/%R markers are ways of implementing the IL language
>> I suggested in that message. So, as
On Wed, Apr 10, 2013 at 09:04:06PM -0500, Gabriel Dos Reis wrote:
> We might be saying the same thing using different languages.
>
> I was the %r/%R markers are ways of implementing the IL language
> I suggested in that message. So, as such I do not object to it.
> Having an explicit call makes t
On Wed, Apr 10, 2013 at 12:54 PM, Manuel López-Ibáñez
wrote:
> On 8 April 2013 21:06, Jakub Jelinek wrote:
>> On Mon, Apr 08, 2013 at 07:54:18PM +0200, Manuel López-Ibáñez wrote:
>>> > can be right now a single call, while you would need several. Also, if
>>> > you
>>> > eventually want to colo
On 8 April 2013 21:06, Jakub Jelinek wrote:
> On Mon, Apr 08, 2013 at 07:54:18PM +0200, Manuel López-Ibáñez wrote:
>> > can be right now a single call, while you would need several. Also, if you
>> > eventually want to colorize something in say error_at, warning_at and
>> > similar format strings
On Mon, Apr 08, 2013 at 07:54:18PM +0200, Manuel López-Ibáñez wrote:
> > can be right now a single call, while you would need several. Also, if you
> > eventually want to colorize something in say error_at, warning_at and
> > similar format strings. For those you really don't have the printer at
On 8 April 2013 16:43, Jakub Jelinek wrote:
> On Mon, Apr 08, 2013 at 04:29:02PM +0200, Manuel López-Ibáñez wrote:
>> In fact, I would be fine with something like:
>>
>> pp_start_color()
>> pp_stop_color()
>> pp_wrap_in_color("")
>>
>> It is a bit more verbose, but also clearer when reading the co
On Mon, Apr 08, 2013 at 04:29:02PM +0200, Manuel López-Ibáñez wrote:
> In fact, I would be fine with something like:
>
> pp_start_color()
> pp_stop_color()
> pp_wrap_in_color("")
>
> It is a bit more verbose, but also clearer when reading the code. And
> no need for %[colorname] or %r or -Wformat
On 8 April 2013 15:23, Jakub Jelinek wrote:
> On Fri, Apr 05, 2013 at 11:51:43PM +0200, Manuel López-Ibáñez wrote:
>> In this patch the default is "never", because for some reason "auto"
>> triggers colorization during regression testing. I have not found a
>
> That reason is obvious, dejagnu (exp
On Fri, Apr 05, 2013 at 11:51:43PM +0200, Manuel López-Ibáñez wrote:
> In this patch the default is "never", because for some reason "auto"
> triggers colorization during regression testing. I have not found a
That reason is obvious, dejagnu (expect?) creates pseudo terminals, so
isatty is true, w
On 2 April 2013 11:14, Jakub Jelinek wrote:
>
> Yeah, IMHO we definitely want to support GCC_COLORS env var or similar, with
> same syntax as e.g. GREP_COLORS, but with different names of the (two
> letter?) color names.
The attached patch adds support for customization via GCC_COLORS
following g
On Tue, Apr 02, 2013 at 04:26:37AM -0500, Gabriel Dos Reis wrote:
> > IMO we also want that autodetection and default to auto.
>
> I disagree.
> For this release, I think the default should be off. We need more
I think a year is plenty of time to agree on the default color scheme
(and yes, the d
On Tue, Apr 2, 2013 at 4:14 AM, Jakub Jelinek wrote:
> Yeah, IMHO we definitely want to support GCC_COLORS env var or similar, with
> same syntax as e.g. GREP_COLORS, but with different names of the (two
> letter?) color names.
Agreed.
>> This patch only allows two options enable/disable colors
On Sun, Mar 31, 2013 at 10:01:21PM +0200, Manuel López-Ibáñez wrote:
> The following patch implements an option that allows printing the
> diagnostics markers ("error:", "warning:", "note:") in different
> colors (red, magenta, and green, respectively).
Thanks for working on that.
> I followed th
On 31 March 2013 22:11, Andrew Pinski wrote:
>
> A couple of things. I think should be able to control the coloring by
> a real environment variable like LS_COLOR allows.
> fdiagnostics-show-color should be controllable by an env variable so
> you don't have to pass an argument to gcc all the tim
On Sun, Mar 31, 2013 at 1:01 PM, Manuel López-Ibáñez
wrote:
> The following patch implements an option that allows printing the
> diagnostics markers ("error:", "warning:", "note:") in different
> colors (red, magenta, and green, respectively).
>
> I followed the implementation of GNU grep but we
The following patch implements an option that allows printing the
diagnostics markers ("error:", "warning:", "note:") in different
colors (red, magenta, and green, respectively).
I followed the implementation of GNU grep but we cannot directly use
their code, since they only care about printing to
20 matches
Mail list logo
