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

Re: [PATCH v13 04/12] ref-filter: implement an `align` atom

From
Karthik Nayak <karthik.188@gmail.com>
Date
Aug 25, 2015, 13:28 UTC
Message-ID
<CAOLa=ZReeQQ6sV3WvmjcYqQTg+s2xm3cepVe25gEH4jcAx3ocg@mail.gmail.com>
In-Reply-To
<xmqqmvxg2v3u.fsf@gitster.dls.corp.google.com>
On Tue, Aug 25, 2015 at 3:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 28 quoted lines
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> +static void perform_quote_formatting(struct strbuf *s, const char *str, int quote_style);
>> +
>> +static void end_atom_handler(struct atom_value *atomv, struct ref_formatting_state *state)
>> +{
>> +     struct ref_formatting_stack *current = state->stack;
>> +     struct strbuf s = STRBUF_INIT;
>> +
>> +     if (!current->at_end)
>> +             die(_("format: `end` atom used without a supporting atom"));
>> +     current->at_end(current);
>> +     /*
>> +      * Whenever we have more than one stack element that means we
>> +      * are using a certain modifier atom. In that case we need to
>> +      * perform quote formatting.
>> +      */
>> +     if (!state->stack->prev->prev) {
>
> The comment and the condition seem to be saying opposite things.
> The code says "If the stack only has one prev that is the very
> initial one, then we do the quoting, i.e. the result of expanding
> the enclosed string in %(start-something)...%(end) is quoted only
> when that appears at the top level", which feels more correct than
> the comment that says "if we are about to pop after seeing the
> first %(end) in %(start)...%(another)...%(end)...%(end) sequence,
> we quote what is between %(another)...%(end)".
>
That sounds misleading indeed will need to change that.
Show 96 quoted lines
>> +             perform_quote_formatting(&s, current->output.buf, state->quote_style);
>> +             strbuf_reset(&current->output);
>> +             strbuf_addbuf(&current->output, &s);
>> +     }
>> +     strbuf_release(&s);
>> +     pop_stack_element(&state->stack);
>> +}
>> +
>
>> @@ -1228,29 +1315,33 @@ void ref_array_sort(struct ref_sorting *sorting, struct ref_array *array)
>>       qsort(array->items, array->nr, sizeof(struct ref_array_item *), compare_refs);
>>  }
>>
>> -static void append_atom(struct atom_value *v, struct ref_formatting_state *state)
>> +static void perform_quote_formatting(struct strbuf *s, const char *str, int quote_style)
>>  {
>> -     struct strbuf *s = &state->stack->output;
>> -
>> -     switch (state->quote_style) {
>> +     switch (quote_style) {
>>       case QUOTE_NONE:
>> -             strbuf_addstr(s, v->s);
>> +             strbuf_addstr(s, str);
>>               break;
>>       case QUOTE_SHELL:
>> -             sq_quote_buf(s, v->s);
>> +             sq_quote_buf(s, str);
>>               break;
>>       case QUOTE_PERL:
>> -             perl_quote_buf(s, v->s);
>> +             perl_quote_buf(s, str);
>>               break;
>>       case QUOTE_PYTHON:
>> -             python_quote_buf(s, v->s);
>> +             python_quote_buf(s, str);
>>               break;
>>       case QUOTE_TCL:
>> -             tcl_quote_buf(s, v->s);
>> +             tcl_quote_buf(s, str);
>>               break;
>>       }
>>  }
>>
>> +static void append_atom(struct atom_value *v, struct ref_formatting_state *state)
>> +{
>> +     struct strbuf *s = &state->stack->output;
>> +     perform_quote_formatting(s, v->s, state->quote_style);
>
> Hmmm, do we want to unconditionally do the quote here, or only when
> we are not being captured by upcoming %(end) to be consistent with
> the behaviour of end_atom_handler() above?
>
>> @@ -1307,7 +1398,18 @@ void show_ref_array_item(struct ref_array_item *info, const char *format, int qu
>>               if (cp < sp)
>>                       append_literal(cp, sp, &state);
>>               get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep), &atomv);
>> -             append_atom(atomv, &state);
>> +             /*
>> +              * If the atom is a modifier atom, then call the handler function.
>> +              * Else, if this is the first element on the stack, then we need to
>> +              * format the atom as per the given quote. Else we just add the atom value
>> +              * to the current stack element and handle quote formatting at the end.
>> +              */
>> +             if (atomv->handler)
>> +                     atomv->handler(atomv, &state);
>> +             else if (!state.stack->prev)
>> +                     append_atom(atomv, &state);
>> +             else
>> +                     strbuf_addstr(&state.stack->output, atomv->s);
>
> Ahh, this explains why you are not doing it above, but I do not
> think if this is a good division of labor.
>
> You can see that I expected that "if !state.stack->prev" check to be
> inside append_atom(), and I would imagine future readers would have
> the same expectation when reading this code.  I.e.
>
>         append_atom(struct atom_value *v, struct ref_f_s *state)
>         {
>                 if (state->stack->prev)
>                         strbuf_addstr(&state->stack->output, v->s);
>                 else
>                         quote_format(&state->stack->output, v->s, state->quote_style);
>         }
>
> The end result may be the same, but I do think "append_atom is to
> always quote, so we do an unquoted appending by hand" is a bad way
> to do this.
>
> Moreover, notice that the function signature of append_atom() is
> exactly the same as atomv->handler's.  I wonder if it would be
> easier to understand if you made append_atom() the handler for a
> non-magic atoms, which would let you do the above without any if/else
> and just a single unconditional
>
>         atomv->handler(atomv, &state);
I like the atomv->handler() idea I think I'll work on that now.
-- 
Regards,
Karthik Nayak
Previous: Junio C HamanoNext: Karthik Nayak
Message 16 of 60 in “port tag.c to use ref-filter APIs”
  1. 00/12 port tag.c to use ref-filter APIsKarthik Nayak, Aug 22, 2015
  2. 01/12 ref-filter: move `struct atom_value` to ref-filter.cKarthik Nayak, Aug 22, 2015
  3. 02/12 ref-filter: introduce ref_formatting_state and ref_formatting_stackKarthik Nayak, Aug 22, 2015
  4. Junio C HamanoAug 24, 2015
  5. Karthik NayakAug 25, 2015
  6. 03/12 utf8: add function to align a string into given strbufKarthik Nayak, Aug 22, 2015
  7. 04/12 ref-filter: implement an `align` atomKarthik Nayak, Aug 22, 2015
  8. Junio C HamanoAug 24, 2015
  9. Junio C HamanoAug 24, 2015
  10. Karthik NayakAug 25, 2015
  11. Matthieu MoyAug 25, 2015
  12. Karthik NayakAug 25, 2015
  13. Junio C HamanoAug 25, 2015
  14. Karthik NayakAug 26, 2015
  15. Junio C HamanoAug 25, 2015
  16. Karthik NayakAug 25, 2015
  17. 05/12 ref-filter: add option to filter out tags, branches and remotesKarthik Nayak, Aug 22, 2015
  18. Junio C HamanoAug 24, 2015
  19. Karthik NayakAug 25, 2015
  20. Michael HaggertyAug 26, 2015
  21. Karthik NayakAug 27, 2015
  22. Michael HaggertyAug 27, 2015
  23. Karthik NayakAug 27, 2015
  24. 06/12 ref-filter: support printing N lines from tag annotationKarthik Nayak, Aug 22, 2015
  25. 07/12 ref-filter: add support to sort by versionKarthik Nayak, Aug 22, 2015
  26. 08/12 ref-filter: add option to match literal patternKarthik Nayak, Aug 22, 2015
  27. 09/12 tag.c: use 'ref-filter' data structuresKarthik Nayak, Aug 22, 2015
  28. 10/12 tag.c: use 'ref-filter' APIsKarthik Nayak, Aug 22, 2015
  29. 11/12 tag.c: implement '--format' optionKarthik Nayak, Aug 22, 2015
  30. Matthieu MoyAug 23, 2015
  31. Karthik NayakAug 24, 2015
  32. Matthieu MoyAug 24, 2015
  33. Karthik NayakAug 24, 2015
  34. 12/12 tag.c: implement '--merged' and '--no-merged' optionsKarthik Nayak, Aug 22, 2015
  35. Matthieu MoyAug 23, 2015
  36. Karthik NayakAug 24, 2015
  37. Matthieu MoyAug 24, 2015
  38. Karthik NayakAug 24, 2015
  39. Junio C HamanoAug 24, 2015
  40. Junio C HamanoAug 24, 2015
  41. Karthik NayakAug 25, 2015
  42. Junio C HamanoAug 25, 2015
  43. Junio C HamanoAug 25, 2015
  44. Karthik NayakAug 26, 2015
  45. Junio C HamanoAug 26, 2015
  46. Karthik NayakAug 26, 2015
  47. Junio C HamanoAug 26, 2015
  48. Karthik NayakAug 27, 2015
  49. Karthik NayakAug 25, 2015
  50. Junio C HamanoAug 24, 2015
  51. Karthik NayakAug 24, 2015
  52. Junio C HamanoAug 24, 2015
  53. Junio C HamanoAug 24, 2015
  54. Karthik NayakAug 26, 2015
  55. Matthieu MoyAug 26, 2015
  56. Junio C HamanoAug 26, 2015
  57. Junio C HamanoAug 26, 2015
  58. Matthieu MoyAug 26, 2015
  59. Karthik NayakAug 26, 2015
  60. Karthik NayakAug 25, 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.