git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	"christian.couder@gmail.com" <christian.couder@gmail.com>,
	"Matthieu.Moy@grenoble-inp.fr" <Matthieu.Moy@grenoble-inp.fr>,
	"gitster@pobox.com" <gitster@pobox.com>
Subject: [PATCH v6 01/10] ref-filter: introduce 'ref_formatting_state'
Date: Wed, 29 Jul 2015 15:19:36 -0400	[thread overview]
Message-ID: <CAPig+cS+w8ECma--ncJDoN1fEgrFZMvBC8GBgU6+tLYm_oGkaw@mail.gmail.com> (raw)
In-Reply-To: <1438065211-3777-1-git-send-email-Karthik.188@gmail.com>

On Tuesday, July 28, 2015, Karthik Nayak <karthik.188@gmail.com> wrote:
> Introduce 'ref_formatting' structure to hold values of pseudo atoms
> which help only in formatting. This will eventually be used by atoms
> like `color` and the `padright` atom which will be introduced in a
> later patch.

Isn't this commit message outdated now that you no longer treat color
specially and since the terminology is changing from "pseudo" to
"modifier"? Also, isn't the structure now called
'ref_formatting_state' rather than 'ref_formatting'?

> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
> diff --git a/ref-filter.c b/ref-filter.c
> index 7561727..a919a14 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -620,7 +622,7 @@ static void populate_value(struct ref_array_item *ref)
>                 const char *name = used_atom[i];
>                 struct atom_value *v = &ref->value[i];
>                 int deref = 0;
> -               const char *refname;
> +               const char *refname = NULL;

What is this change about? It doesn't seem to be related to anything
else in the patch.

>                 const char *formatp;
>                 struct branch *branch = NULL;
>
> @@ -1190,30 +1192,47 @@ void ref_array_sort(struct ref_sorting *sorting, struct ref_array *array)
> +static void print_value(struct atom_value *v, struct ref_formatting_state *state)
> +{
> +       struct strbuf value = STRBUF_INIT;
> +       struct strbuf formatted = STRBUF_INIT;
> +
> +       /*
> +        * Some (pesudo) atoms have no immediate side effect, but only
> +        * affect the next atom. Store the relevant information from
> +        * these atoms in the 'state' variable for use when displaying
> +        * the next atom.
> +        */
> +       apply_formatting_state(state, v, &value);

The comment says that this is "storing" formatting state, however, the
code is actually "applying" the state. You could move this comment
down to show_ref_array_item() where formatting state actually gets
stored. Or you could fix it to talk about "applying" the state.
However, now that apply_formatting_state() has a meaningful name, you
could also drop the comment altogether since it doesn't say much
beyond what is said already by the function name.

> +       switch (state->quote_style) {
>         case QUOTE_NONE:
> -               fputs(v->s, stdout);
> @@ -1254,9 +1273,26 @@ static void emit(const char *cp, const char *ep)
> +static void reset_formatting_state(struct ref_formatting_state *state)
> +{
> +       int quote_style = state->quote_style;
> +       memset(state, 0, sizeof(*state));
> +       state->quote_style = quote_style;

I wonder if this sledge-hammer approach of saving one or two values
before clearing the entire 'ref_formatting_state' and then restoring
the saved values will scale well. Would it be better for this to just
individually reset the fields which need resetting and not touch those
that don't?

Also, the fact that quote_style has to be handled specially may be an
indication that it doesn't belong in this structure grouped with the
other modifiers or that you need better classification within the
structure. For instance:

    struct ref_formatting_state {
        struct global {
            int quote_style;
        };
        struct local {
            int pad_right;
        };

where 'local' state gets reset by reset_formatting_state(), and
'global' is left alone.

That's just one idea, not necessarily a proposal, but is something to
think about since the current arrangement is kind of yucky.

> +}
> +
>  void show_ref_array_item(struct ref_array_item *info, const char *format, int quote_style)
>  {
>         const char *cp, *sp, *ep;
> +       struct ref_formatting_state state;
> +
> +       memset(&state, 0, sizeof(state));
> +       state.quote_style = quote_style;

It's a little bit ugly to use memset() here when you have
reset_formatting_state() available. You could set quote_style first,
and then call reset_formatting_state() rather than memset(). Or,
perhaps, change reset_formatting_state(), as described above, to stop
using the sledge-hammer approach.

>         for (cp = format; *cp && (sp = find_next(cp)); cp = ep + 1) {
>                 struct atom_value *atomv;

  parent reply	other threads:[~2015-07-29 19:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-28  6:32 [PATCH v6 0/10] port tag.c to use ref-filter APIs Karthik Nayak
2015-07-28  6:33 ` [PATCH v6 01/10] ref-filter: introduce 'ref_formatting_state' Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 02/10] ref-filter: add option to pad atoms to the right Karthik Nayak
2015-07-29 19:29     ` Eric Sunshine
2015-07-30 10:18       ` Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 03/10] ref-filter: add option to filter only tags Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 04/10] ref-filter: support printing N lines from tag annotation Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 05/10] ref-filter: add support to sort by version Karthik Nayak
2015-07-29 19:34     ` Eric Sunshine
2015-07-30 10:23       ` Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 06/10] ref-filter: add option to match literal pattern Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 07/10] tag.c: use 'ref-filter' data structures Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 08/10] tag.c: use 'ref-filter' APIs Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 09/10] tag.c: implement '--format' option Karthik Nayak
2015-07-28  6:33   ` [PATCH v6 10/10] tag.c: implement '--merged' and '--no-merged' options Karthik Nayak
2015-07-28  7:26   ` [PATCH v6 01/10] ref-filter: introduce 'ref_formatting_state' Matthieu Moy
2015-07-29 15:56     ` Karthik Nayak
2015-07-29 16:04       ` Matthieu Moy
2015-07-29 16:10         ` Karthik Nayak
2015-07-29 16:35           ` Matthieu Moy
2015-07-29 19:19   ` Eric Sunshine [this message]
2015-07-29 19:50     ` Junio C Hamano
2015-07-29 19:54     ` Junio C Hamano
2015-07-30  9:18       ` Karthik Nayak
2015-07-30  9:25       ` Matthieu Moy
2015-07-29 21:34     ` Matthieu Moy
2015-07-30  6:53     ` Karthik Nayak
2015-07-29 19:27 ` [PATCH v6 0/10] port tag.c to use ref-filter APIs Eric Sunshine
2015-07-29 20:29   ` Junio C Hamano
2015-07-30  9:44     ` Matthieu Moy
2015-07-30 10:13       ` Karthik Nayak
2015-07-30 15:35 ` [PATCH v7 01/11] ref-filter: introduce 'ref_formatting_state' Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 02/11] ref-filter: make `color` use `ref_formatting_state` Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 03/11] ref-filter: add option to pad atoms to the right Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 04/11] ref-filter: add option to filter only tags Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 05/11] ref-filter: support printing N lines from tag annotation Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 06/11] ref-filter: add support to sort by version Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 07/11] ref-filter: add option to match literal pattern Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 08/11] tag.c: use 'ref-filter' data structures Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 09/11] tag.c: use 'ref-filter' APIs Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 10/11] tag.c: implement '--format' option Karthik Nayak
2015-07-30 15:35   ` [PATCH v7 11/11] tag.c: implement '--merged' and '--no-merged' options Karthik Nayak

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPig+cS+w8ECma--ncJDoN1fEgrFZMvBC8GBgU6+tLYm_oGkaw@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).