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

Re: [PATCH v14 04/13] ref-filter: implement an `align` atom

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Aug 30, 2015, 22:10 UTC
Message-ID
<CAPig+cQF=1FPFP_7Bn2m2J+ay5ZupG25USWc9LT9SqO1=VDZvg@mail.gmail.com>
In-Reply-To
<CAOLa=ZTHtps2gJb9asSzG_4NOwx_xiA7OuCzjW=BTTFfkaYoQg@mail.gmail.com>
On Sun, Aug 30, 2015 at 9:38 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
Show 37 quoted lines
> On Sun, Aug 30, 2015 at 8:57 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>>> +static void append_atom(struct atom_value *v, struct ref_formatting_state *state)
>>> +{
>>> +       /*
>>> +        * Quote formatting is only done when the stack has a single
>>> +        * element. Otherwise quote formatting is done on the
>>> +        * element's entire output strbuf when the %(end) atom is
>>> +        * encountered.
>>> +        */
>>> +       if (!state->stack->prev)
>>
>> With the disclaimer that I wasn't following the quoting discussion
>> closely: Is this condition going to be sufficient for all cases, such
>> as an %(if:) atom? That is, if you have:
>>
>>     %(if:notempty)%(bloop)%(then) --option=%(bloop)%(end)
>>
>> isn't the intention that, %(bloop) within the %(then) section should
>> be quoted but not the literal "--option="?
>>
>> The condition `!state->stack->prev' would be insufficient to handle
>> this if %(if:) pushes one or more states onto the stack, no? This
>> implies that you might want an explicit flag for enabling/disabling
>> quoting rather than relying upon the state of the stack, and that
>> individual atom handlers would control that flag.
>
>> Or, am I misunderstanding due to not having followed the discussion closely?
>
> Yes this wont be work for what you've said.
>
> To sum up the discussion:
> We didn't want atoms within the %(align)....%(end) to be quoted separately
> rather the whole aligned buffer to be quoted at the end.
>
> But this does conflict with %(if)...%(end). So it makes sense to change it to
> only have checks for %(align) atom being used.

If I understand Junio's response correctly, then this doesn't sound correct either. Rather than imbuing only %(align:) with special quoting knowledge, it sounds like quoting should be handled generically for all top-level atoms and pseudo-atoms, including %(if:) and others which may come later.

(But perhaps I'm still misunderstanding...)
Show 6 quoted lines
> So probably:
>
> static void append_atom(struct atom_value *v, struct
> ref_formatting_state *state)
> {
>     if (state->stack->at_end == align_handler)

This couples append_atom() far too tightly with the %(align:) atom. If you really need to do this sort of special-casing, then it probably would make more sense to have an explicit flag saying whether or not quoting should be done, rather than tying it specifically to the %(align:) atom.

However, (again, if I'm understanding Junio's response), your original `!state->stack->prev' condition might be sufficient after all.

Show 22 quoted lines
>         strbuf_addstr(&state->stack->output, v->s);
>     else
>         quote_formatting(&state->stack->output, v->s, state->quote_style);
> }
>
> and
>
> 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 align modifier atom. In that case we need to
>      * perform quote formatting.
>      */
>     if (current->at_end == align_handler) {

Ditto about being too tightly coupled to %(align:). Such logic should likely be generic for any such atom.

Show 25 quoted lines
>         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);
> }
>>> @@ -725,6 +818,37 @@ static void populate_value(struct ref_array_item *ref)
>>>                         else
>>>                                 v->s = " ";
>>>                         continue;
>>> +               } else if (!strcmp(name, "align"))
>>> +                       die(_("format: incomplete use of the `align` atom"));
>>
>> Why does %(align) get flagged as a malformation of %(align:), whereas
>> %(color) does not get flagged as a malformation of %(color:)? Why does
>> one deserve special treatment but not the other?
>
> Didn't see that, I think its needed to add a check for both like :
>
> else if (!strcmp(name, "align") || !strcmp(name, "color"))
>             die(_("format: improper usage of %s atom"), name);
>
> I had a look if any other atoms need a subvalue to operate, couldn't
> find any.

Hmm, I'm not convinced that either %(align) or %(color) need to be called out specially. What is the current behavior when these "malformations" or any other misspelled atoms are used? Does it error out? Does it simply ignore them and pass them through to the output unmolested?

Previous: Karthik NayakNext: Karthik Nayak
Message 10 of 52 in “Port tag.c to use ref-filter.c”
  1. 00/13 Port tag.c to use ref-filter.cKarthik Nayak, Aug 29, 2015
  2. 01/13 ref-filter: move `struct atom_value` to ref-filter.cKarthik Nayak, Aug 29, 2015
  3. 02/13 ref-filter: introduce ref_formatting_state and ref_formatting_stackKarthik Nayak, Aug 29, 2015
  4. 03/13 utf8: add function to align a string into given strbufKarthik Nayak, Aug 29, 2015
  5. Torsten BögershausenAug 29, 2015
  6. Karthik NayakAug 29, 2015
  7. 04/13 ref-filter: implement an `align` atomKarthik Nayak, Aug 29, 2015
  8. Eric SunshineAug 30, 2015
  9. Karthik NayakAug 30, 2015
  10. Eric SunshineAug 30, 2015
  11. Karthik NayakAug 31, 2015
  12. Eric SunshineAug 31, 2015
  13. Matthieu MoyAug 31, 2015
  14. Eric SunshineAug 31, 2015
  15. Karthik NayakSep 1, 2015
  16. Matthieu MoySep 1, 2015
  17. Karthik NayakSep 1, 2015
  18. Karthik NayakAug 30, 2015
  19. Eric SunshineAug 30, 2015
  20. Karthik NayakAug 31, 2015
  21. Junio C HamanoAug 30, 2015
  22. Eric SunshineAug 30, 2015
  23. Karthik NayakAug 31, 2015
  24. Karthik NayakAug 31, 2015
  25. Matthieu MoyAug 31, 2015
  26. Karthik NayakAug 31, 2015
  27. 05/13 ref-filter: add option to filter out tags, branches and remotesKarthik Nayak, Aug 29, 2015
  28. Eric SunshineAug 30, 2015
  29. Karthik NayakAug 30, 2015
  30. Eric SunshineAug 30, 2015
  31. 06/13 ref-filter: introduce format_ref_array_item()Karthik Nayak, Aug 29, 2015
  32. Eric SunshineAug 30, 2015
  33. Karthik NayakAug 30, 2015
  34. Karthik NayakAug 30, 2015
  35. 07/13 ref-filter: add support for %(contents:lines=X)Karthik Nayak, Aug 29, 2015
  36. Eric SunshineAug 30, 2015
  37. Karthik NayakAug 30, 2015
  38. Eric SunshineAug 30, 2015
  39. Karthik NayakAug 30, 2015
  40. Eric SunshineAug 30, 2015
  41. Karthik NayakAug 31, 2015
  42. 08/13 ref-filter: add support to sort by versionKarthik Nayak, Aug 29, 2015
  43. 09/13 ref-filter: add option to match literal patternKarthik Nayak, Aug 29, 2015
  44. 10/13 tag.c: use 'ref-filter' data structuresKarthik Nayak, Aug 29, 2015
  45. 11/13 tag.c: use 'ref-filter' APIsKarthik Nayak, Aug 29, 2015
  46. 12/13 tag.c: implement '--format' optionKarthik Nayak, Aug 29, 2015
  47. 13/13 tag.c: implement '--merged' and '--no-merged' optionsKarthik Nayak, Aug 29, 2015
  48. Matthieu MoyAug 31, 2015
  49. Karthik NayakAug 31, 2015
  50. Matthieu MoyAug 31, 2015
  51. Karthik NayakAug 31, 2015
  52. Karthik NayakSep 1, 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.