{"thread":{"id":"48961","subject":"[PATCH] RFC Highlight keywords in remote sideband output.","startedAt":"2018-07-26T17:18:11Z","lastAt":"2018-07-30T12:24:39Z","messageCount":4,"participants":["Han-Wen Nienhuys","Stefan Beller","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"353662","messageId":"20180726171751.178616-1-hanwen@google.com","threadId":"48961","inReplyTo":null,"subject":"[PATCH] RFC Highlight keywords in remote sideband output.","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2018-07-26T17:17:51Z","receivedAt":"2018-07-26T17:18:11Z","isPatch":true,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Supported keywords are \"error\", \"warning\", \"hint\" and \"success\".\n\nTODO:\n * make the coloring optional? What variable to use?\n * doc for the coloring option.\n * how to test?\n\nSigned-off-by: Han-Wen Nienhuys <hanwen@google.com>\nChange-Id: I090412a1288bc2caef0916447e28c2d0199da47d\n---\n sideband.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++-------\n 1 file changed, 60 insertions(+), 9 deletions(-)\n\ndiff --git a/sideband.c b/sideband.c\nindex 325bf0e97..c8b7cb6dd 100644\n--- a/sideband.c\n+++ b/sideband.c\n@@ -1,6 +1,53 @@\n #include \"cache.h\"\n #include \"pkt-line.h\"\n #include \"sideband.h\"\n+#include \"color.h\"\n+\n+/*\n+ * Optionally highlight some keywords in remote output if they appear at the\n+ * start of the line.\n+ */\n+void emit_sideband(struct strbuf *dest, const char *src, int n) {\n+        // NOSUBMIT - maybe use transport.color property?\n+        int want_color = want_color_stderr(GIT_COLOR_AUTO);\n+\n+        if (!want_color) {\n+                strbuf_add(dest, src, n);\n+                return;\n+        }\n+\n+        struct kwtable {\n+                const char* keyword;\n+                const char* color;\n+        } keywords[] = {\n+                {\"hint\", GIT_COLOR_YELLOW},\n+                {\"warning\", GIT_COLOR_BOLD_YELLOW},\n+                {\"success\", GIT_COLOR_BOLD_GREEN},\n+                {\"error\", GIT_COLOR_BOLD_RED},\n+                {},\n+        };\n+\n+        while (isspace(*src)) {\n+                strbuf_addch(dest, *src);\n+                src++;\n+                n--;\n+        }\n+\n+        for (struct kwtable* p = keywords; p->keyword; p++) {\n+                int len = strlen(p->keyword);\n+                if (!strncasecmp(p->keyword, src, len) && !isalnum(src[len])) {\n+                        strbuf_addstr(dest, p->color);\n+                        strbuf_add(dest, src, len);\n+                        strbuf_addstr(dest, GIT_COLOR_RESET);\n+                        n -= len;\n+                        src += len;\n+                        break;\n+                }\n+        }\n+\n+        strbuf_add(dest, src, n);\n+}\n+\n \n /*\n  * Receive multiplexed output stream over git native protocol.\n@@ -48,8 +95,10 @@ int recv_sideband(const char *me, int in_stream, int out)\n \t\tlen--;\n \t\tswitch (band) {\n \t\tcase 3:\n-\t\t\tstrbuf_addf(&outbuf, \"%s%s%s\", outbuf.len ? \"\\n\" : \"\",\n-\t\t\t\t    DISPLAY_PREFIX, buf + 1);\n+\t\t\tstrbuf_addf(&outbuf, \"%s%s\", outbuf.len ? \"\\n\" : \"\",\n+\t\t\t\t    DISPLAY_PREFIX);\n+                        emit_sideband(&outbuf, buf+1, len);\n+\n \t\t\tretval = SIDEBAND_REMOTE_ERROR;\n \t\t\tbreak;\n \t\tcase 2:\n@@ -69,20 +118,22 @@ int recv_sideband(const char *me, int in_stream, int out)\n \t\t\t\tif (!outbuf.len)\n \t\t\t\t\tstrbuf_addstr(&outbuf, DISPLAY_PREFIX);\n \t\t\t\tif (linelen > 0) {\n-\t\t\t\t\tstrbuf_addf(&outbuf, \"%.*s%s%c\",\n-\t\t\t\t\t\t    linelen, b, suffix, *brk);\n-\t\t\t\t} else {\n-\t\t\t\t\tstrbuf_addch(&outbuf, *brk);\n+                                        emit_sideband(&outbuf, b, linelen);\n+                                        strbuf_addstr(&outbuf, suffix);\n \t\t\t\t}\n+\n+                                strbuf_addch(&outbuf, *brk);\n \t\t\t\txwrite(2, outbuf.buf, outbuf.len);\n \t\t\t\tstrbuf_reset(&outbuf);\n \n \t\t\t\tb = brk + 1;\n \t\t\t}\n \n-\t\t\tif (*b)\n-\t\t\t\tstrbuf_addf(&outbuf, \"%s%s\", outbuf.len ?\n-\t\t\t\t\t    \"\" : DISPLAY_PREFIX, b);\n+\t\t\tif (*b) {\n+\t\t\t\tstrbuf_addstr(&outbuf, outbuf.len ?\n+\t\t\t\t\t    \"\" : DISPLAY_PREFIX);\n+                                emit_sideband(&outbuf, b, strlen(b));\n+                        }\n \t\t\tbreak;\n \t\tcase 1:\n \t\t\twrite_or_die(out, buf + 1, len);\n-- \n2.18.0.233.g985f88cf7e-goog\n\n"},{"id":"353665","messageId":"CAGZ79kaj3ptbSrWfrZhRjcz1fsCmO_sR5qCfL=F1ZYwwJRBaMA@mail.gmail.com","threadId":"48961","inReplyTo":"20180726171751.178616-1-hanwen@google.com","subject":"Re: [PATCH] RFC Highlight keywords in remote sideband output.","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-07-26T17:53:17Z","receivedAt":"2018-07-26T17:53:31Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jul 26, 2018 at 10:18 AM Han-Wen Nienhuys <hanwen@google.com> wrote:\n>\n> Supported keywords are \"error\", \"warning\", \"hint\" and \"success\".\n\nThanks for taking this upstream. :-)\n\n>\n> TODO:\n>  * make the coloring optional? What variable to use?\n\nThis is the natural extension of the topic merged at a56fb3dcc09\n(Merge branch 'js/colored-push-errors', 2018-05-08), which was merged\nrather recently, so I'd think extending the color.transport option would be\nuseful here. (cc'd the authors of that series)\n\n>  * doc for the coloring option.\n\n\n\n>  * how to test?\n\nI think the best way to get started with a test is to be inspired by\n8301266afa4 (push: test to verify that push errors are colored,\n2018-04-21) from that series.\n\n> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>\n> Change-Id: I090412a1288bc2caef0916447e28c2d0199da47d\n\nWe do not do Change-Ids in git upstream. :/\nAs different workflows have different edges, everyone has their own\nlittle script to deal with those. For example Brandon has\nhttps://github.com/bmwill/dotfiles/blob/master/bin/check-patch\nthat contains a section to remove change ids\n\n    # Remove Change-Id from patch\n    sed -i \"/Change-Id:/d\" \"$f\"\n\n> +void emit_sideband(struct strbuf *dest, const char *src, int n) {\n\nCoding style: we start the brace in the next line for new functions\n(but not after if/while/for)\n\nAlso I did not think hard enough in the internal review, as this function\nis not emitting to the sideband. that is solely done by the xwrite\ncall in recv_sideband. So maybe prepare_sideband would be a better\nname?\n\n\n> +        // NOSUBMIT - maybe use transport.color property?\n\nYes, that would be my suggestion (note that we do not use // comments)\n\n> +        int want_color = want_color_stderr(GIT_COLOR_AUTO);\n> +\n> +        if (!want_color) {\n> +                strbuf_add(dest, src, n);\n> +                return;\n> +        }\n> +\n> +        struct kwtable {\n> +                const char* keyword;\n> +                const char* color;\n> +        } keywords[] = {\n> +                {\"hint\", GIT_COLOR_YELLOW},\n> +                {\"warning\", GIT_COLOR_BOLD_YELLOW},\n> +                {\"success\", GIT_COLOR_BOLD_GREEN},\n> +                {\"error\", GIT_COLOR_BOLD_RED},\n> +                {},\n> +        };\n> +\n> +        while (isspace(*src)) {\n> +                strbuf_addch(dest, *src);\n> +                src++;\n> +                n--;\n> +        }\n> +\n> +        for (struct kwtable* p = keywords; p->keyword; p++) {\n> +                int len = strlen(p->keyword);\n> +                if (!strncasecmp(p->keyword, src, len) && !isalnum(src[len])) {\n> +                        strbuf_addstr(dest, p->color);\n> +                        strbuf_add(dest, src, len);\n> +                        strbuf_addstr(dest, GIT_COLOR_RESET);\n> +                        n -= len;\n> +                        src += len;\n> +                        break;\n> +                }\n> +        }\n> +\n> +        strbuf_add(dest, src, n);\n> +}\n> +\n>\n>  /*\n>   * Receive multiplexed output stream over git native protocol.\n> @@ -48,8 +95,10 @@ int recv_sideband(const char *me, int in_stream, int out)\n>                 len--;\n>                 switch (band) {\n>                 case 3:\n> -                       strbuf_addf(&outbuf, \"%s%s%s\", outbuf.len ? \"\\n\" : \"\",\n> -                                   DISPLAY_PREFIX, buf + 1);\n> +                       strbuf_addf(&outbuf, \"%s%s\", outbuf.len ? \"\\n\" : \"\",\n> +                                   DISPLAY_PREFIX);\n> +                        emit_sideband(&outbuf, buf+1, len);\n> +\n>                         retval = SIDEBAND_REMOTE_ERROR;\n>                         break;\n>                 case 2:\n> @@ -69,20 +118,22 @@ int recv_sideband(const char *me, int in_stream, int out)\n>                                 if (!outbuf.len)\n>                                         strbuf_addstr(&outbuf, DISPLAY_PREFIX);\n>                                 if (linelen > 0) {\n> -                                       strbuf_addf(&outbuf, \"%.*s%s%c\",\n> -                                                   linelen, b, suffix, *brk);\n> -                               } else {\n> -                                       strbuf_addch(&outbuf, *brk);\n> +                                        emit_sideband(&outbuf, b, linelen);\n> +                                        strbuf_addstr(&outbuf, suffix);\n>                                 }\n> +\n> +                                strbuf_addch(&outbuf, *brk);\n>                                 xwrite(2, outbuf.buf, outbuf.len);\n>                                 strbuf_reset(&outbuf);\n>\n>                                 b = brk + 1;\n>                         }\n>\n> -                       if (*b)\n> -                               strbuf_addf(&outbuf, \"%s%s\", outbuf.len ?\n> -                                           \"\" : DISPLAY_PREFIX, b);\n> +                       if (*b) {\n> +                               strbuf_addstr(&outbuf, outbuf.len ?\n> +                                           \"\" : DISPLAY_PREFIX);\n> +                                emit_sideband(&outbuf, b, strlen(b));\n> +                        }\n>                         break;\n>                 case 1:\n>                         write_or_die(out, buf + 1, len);\n> --\n> 2.18.0.233.g985f88cf7e-goog\n>\n"},{"id":"353668","messageId":"xmqqva91q1an.fsf@gitster-ct.c.googlers.com","threadId":"48961","inReplyTo":"20180726171751.178616-1-hanwen@google.com","subject":"Re: [PATCH] RFC Highlight keywords in remote sideband output.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-07-26T18:50:24Z","receivedAt":"2018-07-26T18:50:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han-Wen Nienhuys <hanwen@google.com> writes:\n\n> Supported keywords are \"error\", \"warning\", \"hint\" and \"success\".\n>\n> TODO:\n>  * make the coloring optional? What variable to use?\n>  * doc for the coloring option.\n>  * how to test?\n\nAt the sideband layer, the sender only has the same level of\ninformation as the receiver has regarding what the random bytes that\nhappens to be sent on the sideband, and that shows from the need to\nguess with \"keywords\" in this code.  So if you are operating on the\nsideband layer, I think the right way to do so would be to add the\ncoloring on the receiving end.  That way, talking to the same sender,\neach receiver can decide if s/he prefers or capable of color.\n\n    Hold your objection a bit.  I'll come back to it soon ;-)\n\nIt theoretically may make more sense to color on the sender side,\nbut that is true only if done at a higher layer that prepares a\nstring and calls into the sideband code to send.  That code must\nknow what the bytes _mean_ a lot better than the code at the\nsideband layer, so we do not have to guess.\n\nHaving written all the above, I think you are doing this at the\nreceiving end, so this actually makes quite a lot of sense.  I was\nfooled greatly by \"EMIT_sideband\", which in reality does NOT emit at\nall.  That function is badly misnamed.\n\nThe function is more like \"color sideband payload\"; actual\n\"emitting\" is still done at the places the code originally \"emitted\"\nthem to the receiving user.\n\n> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>\n> Change-Id: I090412a1288bc2caef0916447e28c2d0199da47d\n\nThat's an unusual trailer we do not use in this project.\n\n> ---\n>  sideband.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++-------\n>  1 file changed, 60 insertions(+), 9 deletions(-)\n>\n> diff --git a/sideband.c b/sideband.c\n> index 325bf0e97..c8b7cb6dd 100644\n> --- a/sideband.c\n> +++ b/sideband.c\n> @@ -1,6 +1,53 @@\n>  #include \"cache.h\"\n>  #include \"pkt-line.h\"\n>  #include \"sideband.h\"\n> +#include \"color.h\"\n> +\n> +/*\n> + * Optionally highlight some keywords in remote output if they appear at the\n> + * start of the line.\n> + */\n> +void emit_sideband(struct strbuf *dest, const char *src, int n) {\n\nOpen brace on its own line.\n\n> +        // NOSUBMIT - maybe use transport.color property?\n\nAvoid // comment.\n\n> +        int want_color = want_color_stderr(GIT_COLOR_AUTO);\n> +\n> +        if (!want_color) {\n> +                strbuf_add(dest, src, n);\n> +                return;\n> +        }\n> +\n> +        struct kwtable {\n> +                const char* keyword;\n> +                const char* color;\n\nIn our codebase in C, asterisk sticks to the variable not the type.\n\n> +        } keywords[] = {\n> +                {\"hint\", GIT_COLOR_YELLOW},\n> +                {\"warning\", GIT_COLOR_BOLD_YELLOW},\n> +                {\"success\", GIT_COLOR_BOLD_GREEN},\n> +                {\"error\", GIT_COLOR_BOLD_RED},\n> +                {},\n\nDrop the last sentinel element, and instead stop iteration over the\narray using (i < ARRAY_SIZE(keywords)).\n\n> +        };\n> +\n> +        while (isspace(*src)) {\n> +                strbuf_addch(dest, *src);\n> +                src++;\n> +                n--;\n> +        }\n> +\n> +        for (struct kwtable* p = keywords; p->keyword; p++) {\n\nDoes anybody know if we already use the variable decl inside the\n\"for (...)\" construct like this?  I know we discussed the idea of\nusing it somewhere as a weather-balloon to see if people with exotic\nenvironment would mind, and I certainly do not mind making this\npatch serve as such a weather-baloon, but if that is what we are\ndoing, I want the commit log message clearly marked as such, so that\nwe can later \"git log --grep=C99\" to see how long ago such an\nexperiment started.  \n\nNote that we did attempt to start such an experiment once\n\ncf. https://public-inbox.org/git/20170719181956.15845-1-sbeller@google.com/\n\nbut failed.\n\n\n> +                int len = strlen(p->keyword);\n> +                if (!strncasecmp(p->keyword, src, len) && !isalnum(src[len])) {\n> +                        strbuf_addstr(dest, p->color);\n> +                        strbuf_add(dest, src, len);\n> +                        strbuf_addstr(dest, GIT_COLOR_RESET);\n> +                        n -= len;\n> +                        src += len;\n> +                        break;\n> +                }\n> +        }\n> +\n> +        strbuf_add(dest, src, n);\n> +}\n> +\n\nI wonder how this interacts with exotics like the progress output,\nwhich is essentially a single long line with many CRs sprinkled in,\nsent on many packets?  I offhand do not think of a possible bad\ninteraction, but others may be able to think of some.\n\n>  /*\n>   * Receive multiplexed output stream over git native protocol.\n> @@ -48,8 +95,10 @@ int recv_sideband(const char *me, int in_stream, int out)\n>  \t\tlen--;\n>  \t\tswitch (band) {\n>  \t\tcase 3:\n> -\t\t\tstrbuf_addf(&outbuf, \"%s%s%s\", outbuf.len ? \"\\n\" : \"\",\n> -\t\t\t\t    DISPLAY_PREFIX, buf + 1);\n> +\t\t\tstrbuf_addf(&outbuf, \"%s%s\", outbuf.len ? \"\\n\" : \"\",\n> +\t\t\t\t    DISPLAY_PREFIX);\n> +                        emit_sideband(&outbuf, buf+1, len);\n> +\n\nLet's not lose SP around \"+\" on both sides.\n\nAlso you seem to be indenting some lines with all SP and some with\nmixture of HT and SP.  We prefer to use as many 8-column HT and then\nfill the remainder with SP if needed to align with the opening\nparenthesis on line above it (imitate the way strbuf_addf() is split\ninto two lines in the original in this hunk).\n\n> @@ -69,20 +118,22 @@ int recv_sideband(const char *me, int in_stream, int out)\n>  \t\t\t\tif (!outbuf.len)\n>  \t\t\t\t\tstrbuf_addstr(&outbuf, DISPLAY_PREFIX);\n>  \t\t\t\tif (linelen > 0) {\n> -\t\t\t\t\tstrbuf_addf(&outbuf, \"%.*s%s%c\",\n> -\t\t\t\t\t\t    linelen, b, suffix, *brk);\n> -\t\t\t\t} else {\n> -\t\t\t\t\tstrbuf_addch(&outbuf, *brk);\n> +                                        emit_sideband(&outbuf, b, linelen);\n> +                                        strbuf_addstr(&outbuf, suffix);\n\nHere, suffix is the \"clear to the end of the line\" sequence (used\nmostly for progress display), so it is correct to exclude that from\nthe call to \"color this sideband payload\" helper.  Good.\n\nThanks.  While there are need for mostly minor fix-ups, the logic\nseems quite sane.  I think we can start without configuration and\nthen \"fix\" it later.  \n\nWhile I am OK with calling that variable \"transport.<something>\", we\nshould not define/explain it as \"color output coming from the other\nend over the wire transport\".  Those who want to see messages\nemitted remotely during \"git fetch\" in color would want to see the\nmessages generated by \"git fetch\" locally painted in the same color\nscheme, so it makes sense to let \"git fetch\" pay attention and honor\nthat variable even for its own locally generated messages.  The\nvariable instead means \"color any message, either generated locally\nor remotely, during an operation that has something to do with\nobject transport\", or something like that.\n\nThanks.\n"},{"id":"353866","messageId":"CAFQ2z_P0_gtNw0NHBYiF=-9ZB6u9VEkq89R4qH_ZTcZ5jfxbkA@mail.gmail.com","threadId":"48961","inReplyTo":"xmqqva91q1an.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] RFC Highlight keywords in remote sideband output.","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2018-07-30T12:24:24Z","receivedAt":"2018-07-30T12:24:39Z","isPatch":true,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"On Thu, Jul 26, 2018 at 8:50 PM Junio C Hamano <gitster@pobox.com> wrote:\n>     Hold your objection a bit.  I'll come back to it soon ;-)\n>\n> It theoretically may make more sense to color on the sender side,\n> but that is true only if done at a higher layer that prepares a\n> string and calls into the sideband code to send.  That code must\n> know what the bytes _mean_ a lot better than the code at the\n> sideband layer, so we do not have to guess.\n>\n> Having written all the above, I think you are doing this at the\n> receiving end, so this actually makes quite a lot of sense.  I was\n> fooled greatly by \"EMIT_sideband\", which in reality does NOT emit at\n> all.  That function is badly misnamed.\n\nfixed.\n\n> The function is more like \"color sideband payload\"; actual\n> \"emitting\" is still done at the places the code originally \"emitted\"\n> them to the receiving user.\n>\n> > Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>\n> > Change-Id: I090412a1288bc2caef0916447e28c2d0199da47d\n>\n> That's an unusual trailer we do not use in this project.\n\nYes, I know. I forgot to strip it from v2 again, though :-(\n\n> > +void emit_sideband(struct strbuf *dest, const char *src, int n) {\n>\n> Open brace on its own line.\n\nDone.\n\n> > +        // NOSUBMIT - maybe use transport.color property?\n>\n> Avoid // comment.\n\nDone\n\n> In our codebase in C, asterisk sticks to the variable not the type.\n\nDone.\n\n> > +        } keywords[] = {\n> > +                {\"hint\", GIT_COLOR_YELLOW},\n> > +                {\"warning\", GIT_COLOR_BOLD_YELLOW},\n> > +                {\"success\", GIT_COLOR_BOLD_GREEN},\n> > +                {\"error\", GIT_COLOR_BOLD_RED},\n> > +                {},\n>\n> Drop the last sentinel element, and instead stop iteration over the\n> array using (i < ARRAY_SIZE(keywords)).\n\nDone.\n\n> > +        for (struct kwtable* p = keywords; p->keyword; p++) {\n>\n> Does anybody know if we already use the variable decl inside the\n> \"for (...)\" construct like this?  I know we discussed the idea of\n> using it somewhere as a weather-balloon to see if people with exotic\n> environment would mind, and I certainly do not mind making this\n> patch serve as such a weather-baloon, but if that is what we are\n> doing, I want the commit log message clearly marked as such, so that\n> we can later \"git log --grep=C99\" to see how long ago such an\n> experiment started.\n\nI elided this. (I had expected for the compile to enforce restrictions\nlike these using --std=c99.)\n\n> >   * Receive multiplexed output stream over git native protocol.\n> > @@ -48,8 +95,10 @@ int recv_sideband(const char *me, int in_stream, int out)\n> >               len--;\n> >               switch (band) {\n> >               case 3:\n> > -                     strbuf_addf(&outbuf, \"%s%s%s\", outbuf.len ? \"\\n\" : \"\",\n> > -                                 DISPLAY_PREFIX, buf + 1);\n> > +                     strbuf_addf(&outbuf, \"%s%s\", outbuf.len ? \"\\n\" : \"\",\n> > +                                 DISPLAY_PREFIX);\n> > +                        emit_sideband(&outbuf, buf+1, len);\n> > +\n>\n> Let's not lose SP around \"+\" on both sides.\n>\n> Also you seem to be indenting some lines with all SP and some with\n> mixture of HT and SP.  We prefer to use as many 8-column HT and then\n> fill the remainder with SP if needed to align with the opening\n> parenthesis on line above it (imitate the way strbuf_addf() is split\n> into two lines in the original in this hunk).\n\nFixed these, I think.\n\n> Thanks.  While there are need for mostly minor fix-ups, the logic\n> seems quite sane.  I think we can start without configuration and\n> then \"fix\" it later.\n\nI need the configuration to be able to test this, though.\n\n> While I am OK with calling that variable \"transport.<something>\", we\n> should not define/explain it as \"color output coming from the other\n> end over the wire transport\".  Those who want to see messages\n> emitted remotely during \"git fetch\" in color would want to see the\n> messages generated by \"git fetch\" locally painted in the same color\n> scheme, so it makes sense to let \"git fetch\" pay attention and honor\n> that variable even for its own locally generated messages.  The\n> variable instead means \"color any message, either generated locally\n> or remotely, during an operation that has something to do with\n> object transport\", or something like that.\n\nI used color.remote for the property,  but I'm happy to colorize the\nbikeshed with another color.\n\n--\n\nGoogle Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich\n\nRegistergericht und -nummer: Hamburg, HRB 86891\n\nSitz der Gesellschaft: Hamburg\n\nGeschäftsführer: Paul Manicle, Halimah DeLaine Prado\n"}]}