All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Karthik Nayak <karthik.188@gmail.com>,
	Git List <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v14 04/13] ref-filter: implement an `align` atom
Date: Mon, 31 Aug 2015 19:28:35 +0200	[thread overview]
Message-ID: <vpqpp235pvg.fsf@anie.imag.fr> (raw)
In-Reply-To: <CAPig+cRAYeF0ZDn5FsHioZr1g4pH3Ay69_3KDb8ZF1USZxzcEg@mail.gmail.com> (Eric Sunshine's message of "Mon, 31 Aug 2015 13:16:23 -0400")

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Mon, Aug 31, 2015 at 5:55 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> On Sun, Aug 30, 2015 at 3:10 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Sun, Aug 30, 2015 at 9:38 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>>>> 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:
>>>>>> +               } 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?
>>
>> It just simply ignores them currently, which is kinda bad, as the user
>> is given no warning, and the atom is ineffective.
>
> Warning about unrecognized atoms may indeed be a good idea, however,
> the current behavior isn't a huge problem since user discovers the
> error when the output fails to match his expectation.

It's a bit worse than it seems: without this change, using --format
'%(align)%(end)' results in Git complaining about %(end) without
matching atom, which is really confusing since you do have a %(align) (I
got it for real while testing a preliminary version).

> This behavior of ignoring unrecognized atoms predates your work,
> doesn't it? If so, it's probably not something you need to address in
> this series.

I wouldn't insist in having it in the series, but now that it's here, I
think we can keep it (if only to shorten the interdiff for the next
iteration).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

  reply	other threads:[~2015-08-31 17:28 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-29 14:12 [PATCH v14 00/13] Port tag.c to use ref-filter.c Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 01/13] ref-filter: move `struct atom_value` to ref-filter.c Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 02/13] ref-filter: introduce ref_formatting_state and ref_formatting_stack Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 03/13] utf8: add function to align a string into given strbuf Karthik Nayak
2015-08-29 17:10   ` Torsten Bögershausen
2015-08-29 17:33     ` Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 04/13] ref-filter: implement an `align` atom Karthik Nayak
2015-08-30  3:27   ` Eric Sunshine
2015-08-30 13:38     ` Karthik Nayak
2015-08-30 22:10       ` Eric Sunshine
2015-08-31  9:55         ` Karthik Nayak
2015-08-31 17:16           ` Eric Sunshine
2015-08-31 17:28             ` Matthieu Moy [this message]
2015-08-31 18:02               ` Eric Sunshine
2015-09-01 13:05                 ` Karthik Nayak
2015-09-01 13:11                   ` Matthieu Moy
2015-09-01 15:13                     ` Karthik Nayak
2015-08-30 14:57     ` Karthik Nayak
2015-08-30 21:59       ` Eric Sunshine
2015-08-31 10:06         ` Karthik Nayak
2015-08-30 17:27     ` Junio C Hamano
2015-08-30 22:56       ` Eric Sunshine
2015-08-31 10:14         ` Karthik Nayak
2015-08-31 10:28           ` Karthik Nayak
2015-08-31  8:30   ` Matthieu Moy
2015-08-31 10:59     ` Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 05/13] ref-filter: add option to filter out tags, branches and remotes Karthik Nayak
2015-08-30  3:30   ` Eric Sunshine
2015-08-30  6:51     ` Karthik Nayak
2015-08-30  7:16       ` Eric Sunshine
2015-08-29 14:12 ` [PATCH v14 06/13] ref-filter: introduce format_ref_array_item() Karthik Nayak
2015-08-30  3:42   ` Eric Sunshine
2015-08-30  6:39     ` Karthik Nayak
2015-08-30  6:49     ` Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 07/13] ref-filter: add support for %(contents:lines=X) Karthik Nayak
2015-08-30  7:53   ` Eric Sunshine
2015-08-30 17:02     ` Karthik Nayak
2015-08-30 17:09       ` Eric Sunshine
2015-08-30 17:17         ` Karthik Nayak
2015-08-30 22:13   ` Eric Sunshine
2015-08-31  4:43     ` Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 08/13] ref-filter: add support to sort by version Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 09/13] ref-filter: add option to match literal pattern Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 10/13] tag.c: use 'ref-filter' data structures Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 11/13] tag.c: use 'ref-filter' APIs Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 12/13] tag.c: implement '--format' option Karthik Nayak
2015-08-29 14:12 ` [PATCH v14 13/13] tag.c: implement '--merged' and '--no-merged' options Karthik Nayak
2015-08-31  6:50 ` [PATCH v14 00/13] Port tag.c to use ref-filter.c Matthieu Moy
2015-08-31 11:09   ` Karthik Nayak
2015-08-31  7:31 ` Matthieu Moy
2015-08-31 11:36   ` Karthik Nayak
2015-09-01 17:37     ` 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

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

  git send-email \
    --in-reply-to=vpqpp235pvg.fsf@anie.imag.fr \
    --to=matthieu.moy@grenoble-inp.fr \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.