git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Han-Wen Nienhuys <hanwen@google.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] Highlight keywords in remote sideband output.
Date: Thu, 2 Aug 2018 13:43:53 +0200	[thread overview]
Message-ID: <CAFQ2z_OZjGykJ6xUwXB69MSChJpPQzc0xBPDw82oA6+tOs00qQ@mail.gmail.com> (raw)
In-Reply-To: <CAPig+cSbibJ7i8LwJqPe06xJObnq6dJdMUnJoC1uAg4zUQq3KA@mail.gmail.com>

On Tue, Jul 31, 2018 at 10:21 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> On Tue, Jul 31, 2018 at 1:37 PM Han-Wen Nienhuys <hanwen@google.com> wrote:
> > Highlight keywords in remote sideband output.
>
> Prefix with the module you're touching, don't capitalize, and drop the
> period. Perhaps:

Done.

>     sideband: highlight keywords in remote sideband output
>
> > The highlighting is done on the client-side. Supported keywords are
> > "error", "warning", "hint" and "success".
> >
> > The colorization is controlled with the config setting "color.remote".
>
> What's the motivation for this change? The commit message should say
> something about that and give an explanation of why this is done
> client-side rather than server-side.

Added

> > Co-authored-by: Duy Nguyen <pclouds@gmail.com>
>
> Helped-by: is more typical.

Done.

> > Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
> > ---
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > @@ -1229,6 +1229,15 @@ color.push::
> > +color.remote::
> > +       A boolean to enable/disable colored remote output. If unset,
> > +       then the value of `color.ui` is used (`auto` by default).
>
> If this is "boolean", what does "auto" mean? Perhaps update the
> description to better match other color-related options.

All other doc entries say "boolean" here too. I'm happy to fix
phrasing of this file in a follow-on change, but let's keep it like
this for consistency.

> > diff --git a/sideband.c b/sideband.c
> > @@ -1,6 +1,97 @@
> > +void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
> > +{
> > +       int i;
> > +
> > +       load_sideband_colors();
> > +       if (!want_color_stderr(sideband_use_color)) {
> > +               strbuf_add(dest, src, n);
> > +               return;
> > +       }
>
> Can load_sideband_colors() be moved below the !want_color_stderr() conditional?

Reorganized this a bit.

> > +
> > +       while (isspace(*src)) {
> > +               strbuf_addch(dest, *src);
> > +               src++;
> > +               n--;
> > +       }
> > +
> > +       for (i = 0; i < ARRAY_SIZE(keywords); i++) {
> > +               struct kwtable* p = keywords + i;
> > +               int len = strlen(p->keyword);
>
> Would it make sense to precompute each keyword length so you don't
> have to recompute them repeatedly, or is that premature optimization?

That is premature optimization.  The next line does a strncasecmp on
the same data so the cost (loading the keywords into CPU cache) is the
same, while precomputing the length makes the code more error prone.

> > +               if (!strncasecmp(p->keyword, src, len) && !isalnum(src[len])) {
>
> So, the strncasecmp() is checking if one of the recognized keywords is
> at the 'src' position, and the !isalnum() ensures that you won't pick
> up something of which the keyword is merely a prefix. For instance,
> you won't mistakenly highlight "successful". It also works correctly
> when 'len' happens to reference the end-of-string NUL. Okay.

added comment.

> > +                       strbuf_addstr(dest, p->color);
> > +                       strbuf_add(dest, src, len);
> > +                       strbuf_addstr(dest, GIT_COLOR_RESET);
> > +                       n -= len;
> > +                       src += len;
> > +                       break;
> > +               }
>
> So, despite the explanation in the commit message, this function isn't
> _generally_ highlighting keywords in the sideband. Instead, it is
> highlighting a keyword only if it finds it at the start of string
> (ignoring whitespace). Perhaps the commit message could be more clear
> about that.

updated message.

> A natural follow-on question is whether strings are fed to this
> function one line at a time or if the incoming string may have
> embedded newlines (in which case, you might need to find a prefix
> following a newline, as well?).

added comment.

--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

  parent reply	other threads:[~2018-08-02 11:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31 17:36 [PATCH 0/2 v3] Highlight keywords in remote sideband output Han-Wen Nienhuys
2018-07-31 17:36 ` [PATCH 1/2] Document git config getter return value Han-Wen Nienhuys
2018-08-01  8:24   ` Eric Sunshine
2018-07-31 17:36 ` [PATCH 2/2] Highlight keywords in remote sideband output Han-Wen Nienhuys
2018-07-31 19:45   ` Junio C Hamano
2018-07-31 20:21   ` Eric Sunshine
2018-08-01 15:41     ` Junio C Hamano
2018-08-01 17:18       ` Han-Wen Nienhuys
2018-08-01 18:16         ` Junio C Hamano
2018-08-02  7:34           ` Han-Wen Nienhuys
2018-08-02 10:24           ` Eric Sunshine
2018-08-02 11:46             ` Han-Wen Nienhuys
2018-08-02 17:37               ` Eric Sunshine
2018-08-02 17:44                 ` Stefan Beller
2018-08-02 11:43     ` Han-Wen Nienhuys [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-07-30 12:26 [PATCH 1/2] Document git config getter return value Han-Wen Nienhuys
2018-07-30 12:26 ` [PATCH 2/2] Highlight keywords in remote sideband output Han-Wen Nienhuys
2018-07-30 12:18 [PATCH 1/2] Document git config getter return value Han-Wen Nienhuys
2018-07-30 12:18 ` [PATCH 2/2] Highlight keywords in remote sideband output Han-Wen Nienhuys

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=CAFQ2z_OZjGykJ6xUwXB69MSChJpPQzc0xBPDw82oA6+tOs00qQ@mail.gmail.com \
    --to=hanwen@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sunshine@sunshineco.com \
    /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: link
Be 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 NNTP newsgroup(s).