git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v9 02/11] ref-filter: introduce ref_formatting_state

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Aug 7, 2015, 00:19 UTC
Message-ID
<CAPig+cQftyjKFi0Qkg_ZVEJ9A+zGSAmFtHwQ-8hCnf8xtU_PEA@mail.gmail.com>
In-Reply-To
<1438692188-14367-2-git-send-email-Karthik.188@gmail.com>
On Tue, Aug 4, 2015 at 8:42 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
Show 10 quoted lines
> Introduce a ref_formatting_state which will eventually hold the values
> of modifier atoms. Implement this within ref-filter.
>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
> +static void apply_formatting_state(struct ref_formatting_state *state, struct strbuf *final)
> +{
> +       /* More formatting options to be evetually added */
> +       strbuf_addbuf(final, state->output);
> +       strbuf_release(state->output);

I guess the idea here is that you intend state->output to be re-used and it is convenient to "clear" it here rather than making that the responsibility of each caller. For re-use, it is more typical to use strbuf_reset() than strbuf_release() (though Junio may disagree[1]).

[1]: http://article.gmane.org/gmane.comp.version-control.git/273094
Show 14 quoted lines
> +}
> +
>  void show_ref_array_item(struct ref_array_item *info, const char *format, int quote_style)
>  {
>         const char *cp, *sp, *ep;
> -       struct strbuf output = STRBUF_INIT;
> +       struct strbuf value = STRBUF_INIT;
> +       struct strbuf final_buf = STRBUF_INIT;
> +       struct ref_formatting_state state;
>         int i;
>
> +       memset(&state, 0, sizeof(state));
> +       state.quote_style = quote_style;
> +       state.output = &value;

It feels strange to assign a local variable reference to state.output, and there's no obvious reason why you should need to do so. I would have instead expected ref_format_state to be declared as:

    struct ref_formatting_state {
       int quote_style;
       struct strbuf output;
    };
and initialized as so:
    memset(&state, 0, sizeof(state));
    state.quote_style = quote_style;
    strbuf_init(&state.output, 0);

(In fact, the memset() isn't even necessary here since you're initializing all fields explicitly, though perhaps you want the memset() because a future patch adds more fields which are not initialized explicitly?)

This still allows re-use via strbuf_reset() mentioned above.

And, of course, you'd want to strbuf_release() it at the end of this function where you're already releasing final_buf.

>         for (cp = format; *cp && (sp = find_next(cp)); cp = ep + 1) {
> -               struct atom_value *atomv;
> +               struct atom_value *atomv = NULL;
What is this change about?
Show 18 quoted lines
>                 ep = strchr(sp, ')');
> -               if (cp < sp)
> -                       emit(cp, sp, &output);
> +               if (cp < sp) {
> +                       emit(cp, sp, &state);
> +                       apply_formatting_state(&state, &final_buf);
> +               }
>                 get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep), &atomv);
> -               print_value(atomv, quote_style, &output);
> +               process_formatting_state(atomv, &state);
> +               print_value(atomv, &state);
> +               apply_formatting_state(&state, &final_buf);
>         }
>         if (*cp) {
>                 sp = cp + strlen(cp);
> -               emit(cp, sp, &output);
> +               emit(cp, sp, &state);
> +               apply_formatting_state(&state, &final_buf);

I'm getting the feeling that these functions (process_formatting_state, print_value, emit, apply_formatting_state) are becoming misnamed (again) with the latest structural changes (but perhaps I haven't read far enough into the series yet?).

process_formatting_state() is rather generic.

print_value() and emit() both imply outputting something, but neither does so anymore.

apply_formatting_state() seems to be more about finalizing the already-formatted output.

Previous: Karthik NayakNext: Karthik Nayak
Message 4 of 21 in “Port tag.c over to use ref-filter APIs”
  1. 0/11 Port tag.c over to use ref-filter APIsKarthik Nayak, Aug 4, 2015
  2. 01/11 ref-filter: print output to strbuf for formattingKarthik Nayak, Aug 4, 2015
  3. 02/11 ref-filter: introduce ref_formatting_stateKarthik Nayak, Aug 4, 2015
  4. Eric SunshineAug 7, 2015
  5. Karthik NayakAug 7, 2015
  6. Eric SunshineAug 7, 2015
  7. Karthik NayakAug 7, 2015
  8. Eric SunshineAug 7, 2015
  9. Karthik NayakAug 7, 2015
  10. Eric SunshineAug 7, 2015
  11. 03/11 ref-filter: implement an `align` atomKarthik Nayak, Aug 4, 2015
  12. 04/11 ref-filter: add option to filter only tagsKarthik Nayak, Aug 4, 2015
  13. 05/11 ref-filter: support printing N lines from tag annotationKarthik Nayak, Aug 4, 2015
  14. 06/11 ref-filter: add support to sort by versionKarthik Nayak, Aug 4, 2015
  15. 07/11 ref-filter: add option to match literal patternKarthik Nayak, Aug 4, 2015
  16. 08/11 tag.c: use 'ref-filter' data structuresKarthik Nayak, Aug 4, 2015
  17. 09/11 tag.c: use 'ref-filter' APIsKarthik Nayak, Aug 4, 2015
  18. 10/11 tag.c: implement '--format' optionKarthik Nayak, Aug 4, 2015
  19. 11/11 tag.c: implement '--merged' and '--no-merged' optionsKarthik Nayak, Aug 4, 2015
  20. Eric SunshineAug 6, 2015
  21. Karthik NayakAug 7, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.