Patchwork color: issue warning in yellow

login
register
mail settings
Submitter via Mercurial-devel
Date Aug. 20, 2018, 1:21 p.m.
Message ID <CAESOdVCB6O1Zv5BQQfc_GkLyGKK+euL_EMr2_rb49wLC3=Coow@mail.gmail.com>
Download mbox | patch
Permalink /patch/33895/
State New
Headers show

Comments

via Mercurial-devel - Aug. 20, 2018, 1:21 p.m.
I think most of us would be happy with this, but I seem to remember Kyle
always saying that it will be unreadable for users who use white background.

On Aug 20, 2018 01:04, "Boris Feld" <boris.feld@octobus.net> wrote:

# HG changeset patch
# User Boris Feld <boris.feld@octobus.net>
# Date 1534290303 -7200
#      Wed Aug 15 01:45:03 2018 +0200
# Node ID 4144148d7aba13ece916c6f735c791ca3d93a249
# Parent  c62184c6299c09d2e8e7be340f9aee138229cb86
# EXP-Topic color-warning
# Available At https://bitbucket.org/octobus/mercurial-devel/
#              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r
4144148d7aba
color: issue warning in yellow

Using a different color for warning/error output help them to stand out and
attract user attention. At Octobus we have been using this setting for years
with good result.

Now that `ui.error` are colored in red, it seems reasonable to color all
other
error output in yellow.

color.status.modified)\x1b[0m (esc)
+  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in
color.status.modified)\x1b[0m (esc)
   M modified
   \x1b[0;32;1mA \x1b[0m\x1b[0;32;1madded\x1b[0m (esc)
   \x1b[0;32;1mA \x1b[0m\x1b[0;32;1mcopied\x1b[0m (esc)
@@ -376,8 +376,8 @@ test 'resolve -l'
   $ hg merge
   merging a
   merging b
-  warning: conflicts while merging a! (edit, then use 'hg resolve --mark')
-  warning: conflicts while merging b! (edit, then use 'hg resolve --mark')
+  \x1b[0;33mwarning: conflicts while merging a! (edit, then use 'hg
resolve --mark')\x1b[0m (esc)
+  \x1b[0;33mwarning: conflicts while merging b! (edit, then use 'hg
resolve --mark')\x1b[0m (esc)
   0 files updated, 0 files merged, 0 files removed, 2 files unresolved
   use 'hg resolve' to retry unresolved file merges or 'hg merge --abort'
to abandon
   [1]
via Mercurial-devel - Aug. 20, 2018, 4:26 p.m.
Bright/bold yellow should be considered unavailable.  "Normal" yellow,
which is closer to brown or maybe gold on many screens, is fine.  At
Google, and I think other tools like clang, generally use magenta I
believe, but I have no strong preference.  Keep in mind that ui.prompt is
also yellow a couple lines below.

On Mon, Aug 20, 2018, 06:22 Martin von Zweigbergk <martinvonz@google.com>
wrote:

> I think most of us would be happy with this, but I seem to remember Kyle
> always saying that it will be unreadable for users who use white background.
>
> On Aug 20, 2018 01:04, "Boris Feld" <boris.feld@octobus.net> wrote:
>
> # HG changeset patch
> # User Boris Feld <boris.feld@octobus.net>
> # Date 1534290303 -7200
> #      Wed Aug 15 01:45:03 2018 +0200
> # Node ID 4144148d7aba13ece916c6f735c791ca3d93a249
> # Parent  c62184c6299c09d2e8e7be340f9aee138229cb86
> # EXP-Topic color-warning
> # Available At https://bitbucket.org/octobus/mercurial-devel/
> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r
> 4144148d7aba
> color: issue warning in yellow
>
> Using a different color for warning/error output help them to stand out and
> attract user attention. At Octobus we have been using this setting for
> years
> with good result.
>
> Now that `ui.error` are colored in red, it seems reasonable to color all
> other
> error output in yellow.
>
> diff --git a/mercurial/color.py b/mercurial/color.py
> --- a/mercurial/color.py
> +++ b/mercurial/color.py
> @@ -119,6 +119,7 @@ except ImportError:
>      'formatvariant.config.default': 'green',
>      'formatvariant.default': '',
>      'histedit.remaining': 'red bold',
> +    'ui.warning': 'yellow',
>      'ui.error': 'red',
>      'ui.prompt': 'yellow',
>      'log.changeset': 'yellow',
> diff --git a/tests/test-pager.t b/tests/test-pager.t
> --- a/tests/test-pager.t
> +++ b/tests/test-pager.t
> @@ -199,7 +199,7 @@ even though stdout is no longer a tty.
>  An invalid pager command name is reported sensibly if we don't have to
>  use shell=True in the subprocess call:
>    $ hg log --limit 3 --config pager.pager=this-command-better-never-exist
> -  missing pager command 'this-command-better-never-exist', skipping pager
> +  \x1b[0;33mmissing pager command 'this-command-better-never-exist',
> skipping pager\x1b[0m (esc)
>    \x1b[0;33mchangeset:   10:46106edeeb38\x1b[0m (esc)
>    tag:         tip
>    user:        test
> diff --git a/tests/test-status-color.t b/tests/test-status-color.t
> --- a/tests/test-status-color.t
> +++ b/tests/test-status-color.t
> @@ -204,7 +204,7 @@ hg status:
>  hg status modified added removed deleted unknown never-existed ignored:
>
>    $ hg status modified added removed deleted unknown never-existed ignored
> -  never-existed: * (glob)
> +  \x1b[0;33mnever-existed: $ENOENT$\x1b[0m (esc)
>    \x1b[0;32;1mA \x1b[0m\x1b[0;32;1madded\x1b[0m (esc)
>    \x1b[0;31;1mR \x1b[0m\x1b[0;31;1mremoved\x1b[0m (esc)
>    \x1b[0;36;1;4m! \x1b[0m\x1b[0;36;1;4mdeleted\x1b[0m (esc)
> @@ -310,9 +310,9 @@ check 'status -q' and some combinations
>  test unknown color
>
>    $ hg --config color.status.modified=periwinkle status
> -  ignoring unknown color/effect 'periwinkle' (configured in
> color.status.modified)
> -  ignoring unknown color/effect 'periwinkle' (configured in
> color.status.modified)
> -  ignoring unknown color/effect 'periwinkle' (configured in
> color.status.modified)
> +  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in
> color.status.modified)\x1b[0m (esc)
> +  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in
> color.status.modified)\x1b[0m (esc)
> +  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in
> color.status.modified)\x1b[0m (esc)
>    M modified
>    \x1b[0;32;1mA \x1b[0m\x1b[0;32;1madded\x1b[0m (esc)
>    \x1b[0;32;1mA \x1b[0m\x1b[0;32;1mcopied\x1b[0m (esc)
> @@ -376,8 +376,8 @@ test 'resolve -l'
>    $ hg merge
>    merging a
>    merging b
> -  warning: conflicts while merging a! (edit, then use 'hg resolve --mark')
> -  warning: conflicts while merging b! (edit, then use 'hg resolve --mark')
> +  \x1b[0;33mwarning: conflicts while merging a! (edit, then use 'hg
> resolve --mark')\x1b[0m (esc)
> +  \x1b[0;33mwarning: conflicts while merging b! (edit, then use 'hg
> resolve --mark')\x1b[0m (esc)
>    0 files updated, 0 files merged, 0 files removed, 2 files unresolved
>    use 'hg resolve' to retry unresolved file merges or 'hg merge --abort'
> to abandon
>    [1]
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
>
>
via Mercurial-devel - Aug. 20, 2018, 6:14 p.m.
On Mon, Aug 20, 2018 at 9:26 AM Kyle Lippincott <spectral@google.com> wrote:

> Bright/bold yellow should be considered unavailable.  "Normal" yellow,
> which is closer to brown or maybe gold on many screens, is fine.
>

Ah, and we already use yellow for a few things (as you also pointed out).
Sorry I didn't even check that.


>   At Google, and I think other tools like clang, generally use magenta I
> believe, but I have no strong preference.  Keep in mind that ui.prompt is
> also yellow a couple lines below.
>

Good point about ui.prompt. Yellow seems like the obvious choice for
warnings, so do we want to change the color for the prompt?


>
> On Mon, Aug 20, 2018, 06:22 Martin von Zweigbergk <martinvonz@google.com>
> wrote:
>
>> I think most of us would be happy with this, but I seem to remember Kyle
>> always saying that it will be unreadable for users who use white background.
>>
>> On Aug 20, 2018 01:04, "Boris Feld" <boris.feld@octobus.net> wrote:
>>
>> # HG changeset patch
>> # User Boris Feld <boris.feld@octobus.net>
>> # Date 1534290303 -7200
>> #      Wed Aug 15 01:45:03 2018 +0200
>> # Node ID 4144148d7aba13ece916c6f735c791ca3d93a249
>> # Parent  c62184c6299c09d2e8e7be340f9aee138229cb86
>> # EXP-Topic color-warning
>> # Available At https://bitbucket.org/octobus/mercurial-devel/
>> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r
>> 4144148d7aba
>> color: issue warning in yellow
>>
>> Using a different color for warning/error output help them to stand out
>> and
>> attract user attention. At Octobus we have been using this setting for
>> years
>> with good result.
>>
>> Now that `ui.error` are colored in red, it seems reasonable to color all
>> other
>> error output in yellow.
>>
>> diff --git a/mercurial/color.py b/mercurial/color.py
>> --- a/mercurial/color.py
>> +++ b/mercurial/color.py
>> @@ -119,6 +119,7 @@ except ImportError:
>>      'formatvariant.config.default': 'green',
>>      'formatvariant.default': '',
>>      'histedit.remaining': 'red bold',
>> +    'ui.warning': 'yellow',
>>      'ui.error': 'red',
>>      'ui.prompt': 'yellow',
>>      'log.changeset': 'yellow',
>> diff --git a/tests/test-pager.t b/tests/test-pager.t
>> --- a/tests/test-pager.t
>> +++ b/tests/test-pager.t
>> @@ -199,7 +199,7 @@ even though stdout is no longer a tty.
>>  An invalid pager command name is reported sensibly if we don't have to
>>  use shell=True in the subprocess call:
>>    $ hg log --limit 3 --config pager.pager=this-command-better-never-exist
>> -  missing pager command 'this-command-better-never-exist', skipping pager
>> +  \x1b[0;33mmissing pager command 'this-command-better-never-exist',
>> skipping pager\x1b[0m (esc)
>>    \x1b[0;33mchangeset:   10:46106edeeb38\x1b[0m (esc)
>>    tag:         tip
>>    user:        test
>> diff --git a/tests/test-status-color.t b/tests/test-status-color.t
>> --- a/tests/test-status-color.t
>> +++ b/tests/test-status-color.t
>> @@ -204,7 +204,7 @@ hg status:
>>  hg status modified added removed deleted unknown never-existed ignored:
>>
>>    $ hg status modified added removed deleted unknown never-existed
>> ignored
>> -  never-existed: * (glob)
>> +  \x1b[0;33mnever-existed: $ENOENT$\x1b[0m (esc)
>>    \x1b[0;32;1mA \x1b[0m\x1b[0;32;1madded\x1b[0m (esc)
>>    \x1b[0;31;1mR \x1b[0m\x1b[0;31;1mremoved\x1b[0m (esc)
>>    \x1b[0;36;1;4m! \x1b[0m\x1b[0;36;1;4mdeleted\x1b[0m (esc)
>> @@ -310,9 +310,9 @@ check 'status -q' and some combinations
>>  test unknown color
>>
>>    $ hg --config color.status.modified=periwinkle status
>> -  ignoring unknown color/effect 'periwinkle' (configured in
>> color.status.modified)
>> -  ignoring unknown color/effect 'periwinkle' (configured in
>> color.status.modified)
>> -  ignoring unknown color/effect 'periwinkle' (configured in
>> color.status.modified)
>> +  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in
>> color.status.modified)\x1b[0m (esc)
>> +  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in
>> color.status.modified)\x1b[0m (esc)
>> +  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in
>> color.status.modified)\x1b[0m (esc)
>>    M modified
>>    \x1b[0;32;1mA \x1b[0m\x1b[0;32;1madded\x1b[0m (esc)
>>    \x1b[0;32;1mA \x1b[0m\x1b[0;32;1mcopied\x1b[0m (esc)
>> @@ -376,8 +376,8 @@ test 'resolve -l'
>>    $ hg merge
>>    merging a
>>    merging b
>> -  warning: conflicts while merging a! (edit, then use 'hg resolve
>> --mark')
>> -  warning: conflicts while merging b! (edit, then use 'hg resolve
>> --mark')
>> +  \x1b[0;33mwarning: conflicts while merging a! (edit, then use 'hg
>> resolve --mark')\x1b[0m (esc)
>> +  \x1b[0;33mwarning: conflicts while merging b! (edit, then use 'hg
>> resolve --mark')\x1b[0m (esc)
>>    0 files updated, 0 files merged, 0 files removed, 2 files unresolved
>>    use 'hg resolve' to retry unresolved file merges or 'hg merge --abort'
>> to abandon
>>    [1]
>> _______________________________________________
>> Mercurial-devel mailing list
>> Mercurial-devel@mercurial-scm.org
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>>
>>
>>
Yuya Nishihara - Aug. 21, 2018, 1:15 p.m.
On Mon, 20 Aug 2018 11:14:23 -0700, Martin von Zweigbergk via Mercurial-devel wrote:
> On Mon, Aug 20, 2018 at 9:26 AM Kyle Lippincott <spectral@google.com> wrote:
> 
> > Bright/bold yellow should be considered unavailable.  "Normal" yellow,
> > which is closer to brown or maybe gold on many screens, is fine.
> >
> 
> Ah, and we already use yellow for a few things (as you also pointed out).
> Sorry I didn't even check that.
> 
> 
> >   At Google, and I think other tools like clang, generally use magenta I
> > believe, but I have no strong preference.  Keep in mind that ui.prompt is
> > also yellow a couple lines below.
> >
> 
> Good point about ui.prompt. Yellow seems like the obvious choice for
> warnings, so do we want to change the color for the prompt?

FWIW, I don't like the red-colored "error" since it's hard to spot in
white-on-black screen. Well, it's readable, but not significant. A plain
"yellow" (i.e. dark yellow) would have the same effect.
Boris Feld - Oct. 17, 2018, 1:17 p.m.
On 21/08/2018 15:15, Yuya Nishihara wrote:
> On Mon, 20 Aug 2018 11:14:23 -0700, Martin von Zweigbergk via Mercurial-devel wrote:
>> On Mon, Aug 20, 2018 at 9:26 AM Kyle Lippincott <spectral@google.com> wrote:
>>
>>> Bright/bold yellow should be considered unavailable.  "Normal" yellow,
>>> which is closer to brown or maybe gold on many screens, is fine.
>>>
>> Ah, and we already use yellow for a few things (as you also pointed out).
>> Sorry I didn't even check that.
>>
>>
>>>   At Google, and I think other tools like clang, generally use magenta I
>>> believe, but I have no strong preference.  Keep in mind that ui.prompt is
>>> also yellow a couple lines below.
>>>
>> Good point about ui.prompt. Yellow seems like the obvious choice for
>> warnings, so do we want to change the color for the prompt?
> FWIW, I don't like the red-colored "error" since it's hard to spot in
> white-on-black screen. Well, it's readable, but not significant. A plain
> "yellow" (i.e. dark yellow) would have the same effect.

I'm not sure what is the status of this series.

Rereading the discussion, it seems like the yellow on white background
is readable. Is there anything else blocking this improvement

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Yuya Nishihara - Oct. 18, 2018, 12:42 p.m.
On Wed, 17 Oct 2018 15:17:58 +0200, Boris FELD wrote:
> On 21/08/2018 15:15, Yuya Nishihara wrote:
> > On Mon, 20 Aug 2018 11:14:23 -0700, Martin von Zweigbergk via Mercurial-devel wrote:
> >> On Mon, Aug 20, 2018 at 9:26 AM Kyle Lippincott <spectral@google.com> wrote:
> >>
> >>> Bright/bold yellow should be considered unavailable.  "Normal" yellow,
> >>> which is closer to brown or maybe gold on many screens, is fine.
> >>>
> >> Ah, and we already use yellow for a few things (as you also pointed out).
> >> Sorry I didn't even check that.
> >>
> >>
> >>>   At Google, and I think other tools like clang, generally use magenta I
> >>> believe, but I have no strong preference.  Keep in mind that ui.prompt is
> >>> also yellow a couple lines below.
> >>>
> >> Good point about ui.prompt. Yellow seems like the obvious choice for
> >> warnings, so do we want to change the color for the prompt?
> > FWIW, I don't like the red-colored "error" since it's hard to spot in
> > white-on-black screen. Well, it's readable, but not significant. A plain
> > "yellow" (i.e. dark yellow) would have the same effect.
> 
> I'm not sure what is the status of this series.
> 
> Rereading the discussion, it seems like the yellow on white background
> is readable. Is there anything else blocking this improvement

I'm not sure either, but for the record, I (and maybe David Demelier) voted
against this. I want an essential part of console output to be white because
that's what I configured for. I'd rather want warning/error messages to be
prefixed with highlighted tags (e.g. <red>abort:</red> blah blah...)
via Mercurial-devel - Oct. 18, 2018, 1:14 p.m.
On Thu, Oct 18, 2018, 05:42 Yuya Nishihara <yuya@tcha.org wrote:

> On Wed, 17 Oct 2018 15:17:58 +0200, Boris FELD wrote:
> > On 21/08/2018 15:15, Yuya Nishihara wrote:
> > > On Mon, 20 Aug 2018 11:14:23 -0700, Martin von Zweigbergk via
> Mercurial-devel wrote:
> > >> On Mon, Aug 20, 2018 at 9:26 AM Kyle Lippincott <spectral@google.com>
> wrote:
> > >>
> > >>> Bright/bold yellow should be considered unavailable.  "Normal"
> yellow,
> > >>> which is closer to brown or maybe gold on many screens, is fine.
> > >>>
> > >> Ah, and we already use yellow for a few things (as you also pointed
> out).
> > >> Sorry I didn't even check that.
> > >>
> > >>
> > >>>   At Google, and I think other tools like clang, generally use
> magenta I
> > >>> believe, but I have no strong preference.  Keep in mind that
> ui.prompt is
> > >>> also yellow a couple lines below.
> > >>>
> > >> Good point about ui.prompt. Yellow seems like the obvious choice for
> > >> warnings, so do we want to change the color for the prompt?
> > > FWIW, I don't like the red-colored "error" since it's hard to spot in
> > > white-on-black screen. Well, it's readable, but not significant. A
> plain
> > > "yellow" (i.e. dark yellow) would have the same effect.
> >
> > I'm not sure what is the status of this series.
> >
> > Rereading the discussion, it seems like the yellow on white background
> > is readable. Is there anything else blocking this improvement
>
> I'm not sure either, but for the record, I (and maybe David Demelier) voted
> against this. I want an essential part of console output to be white
> because
> that's what I configured for. I'd rather want warning/error messages to be
> prefixed with highlighted tags (e.g. <red>abort:</red> blah blah...)
>

I'm for the patch.

I also agree with Yuya that it would be better to color only a short
prefix. That's probably a lot more work and can be done in a follow-up.
However, I understand if Yuya and others think it's too distracting with
all the color before that is done, so I'm also fine with waiting until
that's fixed. Do we have a common prefix for warnings?
Yuya Nishihara - Oct. 18, 2018, 2:17 p.m.
On Thu, 18 Oct 2018 06:14:43 -0700, Martin von Zweigbergk wrote:
> On Thu, Oct 18, 2018, 05:42 Yuya Nishihara <yuya@tcha.org wrote:
> 
> > On Wed, 17 Oct 2018 15:17:58 +0200, Boris FELD wrote:
> > > On 21/08/2018 15:15, Yuya Nishihara wrote:
> > > > On Mon, 20 Aug 2018 11:14:23 -0700, Martin von Zweigbergk via
> > Mercurial-devel wrote:
> > > >> On Mon, Aug 20, 2018 at 9:26 AM Kyle Lippincott <spectral@google.com>
> > wrote:
> > > >>
> > > >>> Bright/bold yellow should be considered unavailable.  "Normal"
> > yellow,
> > > >>> which is closer to brown or maybe gold on many screens, is fine.
> > > >>>
> > > >> Ah, and we already use yellow for a few things (as you also pointed
> > out).
> > > >> Sorry I didn't even check that.
> > > >>
> > > >>
> > > >>>   At Google, and I think other tools like clang, generally use
> > magenta I
> > > >>> believe, but I have no strong preference.  Keep in mind that
> > ui.prompt is
> > > >>> also yellow a couple lines below.
> > > >>>
> > > >> Good point about ui.prompt. Yellow seems like the obvious choice for
> > > >> warnings, so do we want to change the color for the prompt?
> > > > FWIW, I don't like the red-colored "error" since it's hard to spot in
> > > > white-on-black screen. Well, it's readable, but not significant. A
> > plain
> > > > "yellow" (i.e. dark yellow) would have the same effect.
> > >
> > > I'm not sure what is the status of this series.
> > >
> > > Rereading the discussion, it seems like the yellow on white background
> > > is readable. Is there anything else blocking this improvement
> >
> > I'm not sure either, but for the record, I (and maybe David Demelier) voted
> > against this. I want an essential part of console output to be white
> > because
> > that's what I configured for. I'd rather want warning/error messages to be
> > prefixed with highlighted tags (e.g. <red>abort:</red> blah blah...)
> >
> 
> I'm for the patch.
> 
> I also agree with Yuya that it would be better to color only a short
> prefix. That's probably a lot more work and can be done in a follow-up.
> However, I understand if Yuya and others think it's too distracting with
> all the color before that is done, so I'm also fine with waiting until
> that's fixed. Do we have a common prefix for warnings?

I don't think there is, but I think we can make ui.warn() add 'warning: %s'.
If that breaks scripting usage, it can be behind a config knob. Anyway, that
won't be a trivial change, so my position is to wait the release.

Patch

diff --git a/mercurial/color.py b/mercurial/color.py
--- a/mercurial/color.py
+++ b/mercurial/color.py
@@ -119,6 +119,7 @@  except ImportError:
     'formatvariant.config.default': 'green',
     'formatvariant.default': '',
     'histedit.remaining': 'red bold',
+    'ui.warning': 'yellow',
     'ui.error': 'red',
     'ui.prompt': 'yellow',
     'log.changeset': 'yellow',
diff --git a/tests/test-pager.t b/tests/test-pager.t
--- a/tests/test-pager.t
+++ b/tests/test-pager.t
@@ -199,7 +199,7 @@  even though stdout is no longer a tty.
 An invalid pager command name is reported sensibly if we don't have to
 use shell=True in the subprocess call:
   $ hg log --limit 3 --config pager.pager=this-command-better-never-exist
-  missing pager command 'this-command-better-never-exist', skipping pager
+  \x1b[0;33mmissing pager command 'this-command-better-never-exist',
skipping pager\x1b[0m (esc)
   \x1b[0;33mchangeset:   10:46106edeeb38\x1b[0m (esc)
   tag:         tip
   user:        test
diff --git a/tests/test-status-color.t b/tests/test-status-color.t
--- a/tests/test-status-color.t
+++ b/tests/test-status-color.t
@@ -204,7 +204,7 @@  hg status:
 hg status modified added removed deleted unknown never-existed ignored:

   $ hg status modified added removed deleted unknown never-existed ignored
-  never-existed: * (glob)
+  \x1b[0;33mnever-existed: $ENOENT$\x1b[0m (esc)
   \x1b[0;32;1mA \x1b[0m\x1b[0;32;1madded\x1b[0m (esc)
   \x1b[0;31;1mR \x1b[0m\x1b[0;31;1mremoved\x1b[0m (esc)
   \x1b[0;36;1;4m! \x1b[0m\x1b[0;36;1;4mdeleted\x1b[0m (esc)
@@ -310,9 +310,9 @@  check 'status -q' and some combinations
 test unknown color

   $ hg --config color.status.modified=periwinkle status
-  ignoring unknown color/effect 'periwinkle' (configured in
color.status.modified)
-  ignoring unknown color/effect 'periwinkle' (configured in
color.status.modified)
-  ignoring unknown color/effect 'periwinkle' (configured in
color.status.modified)
+  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in
color.status.modified)\x1b[0m (esc)
+  \x1b[0;33mignoring unknown color/effect 'periwinkle' (configured in