All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, christian.couder@gmail.com,
	Matthieu.Moy@grenoble-inp.fr
Subject: Re: [PATCH v16 00/14] port tag.c to use ref-filter APIs
Date: Sun, 06 Sep 2015 23:33:36 -0700	[thread overview]
Message-ID: <xmqqh9n6agcf.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1441479135-5285-1-git-send-email-Karthik.188@gmail.com> (Karthik Nayak's message of "Sun, 6 Sep 2015 00:22:01 +0530")

Karthik Nayak <karthik.188@gmail.com> writes:

> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index d039f40..c5154bb 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -128,13 +128,14 @@ color::
>  	are described in `color.branch.*`.
>  
>  align::
> -	Left-, middle-, or right-align the content between %(align:..)
> +	Left-, middle-, or right-align the content between %(align:...)
>  	and %(end). Followed by `:<width>,<position>`, where the
>  	`<position>` is either left, right or middle and `<width>` is
>  	the total length of the content with alignment. If the
>  	contents length is more than the width then no alignment is
>  	performed. If used with '--quote' everything in between
> -	%(align:..)  and %(end) is quoted.
> +	%(align:...) and %(end) is quoted, but if nested then only the
> +	topmost level performs quoting.

I am not sure if the description of quote belongs to "align".  Isn't
the general rule at the endgame when there are more opening things
that would buffer its effect up to the corresponding %(end):

 - Some atoms like %(align) and %(if) always require a matching
   %(end).  We call them "opening atoms" and sometimes denote them
   as %($open).

 - When a scripting language specific quoting is in effect, except
   for opening atoms, replacement from every %(atom) is quoted when
   and only when it appears at the top-level (that is, when it
   appears outside %($open)...%(end)).

 - When a scripting language specific quoting is in effect,
   everything between a top-level opening atom and its matching
   %(end) is evaluated according to the semantics of the opening
   atom and its result is quoted.

To put the third item above in a different way, a matching
%($open)...  %(end) pair behaves as if it is a single normal atom,
from the point of view of the quoting rule.  All top-level atoms are
invidivually quoted, whether they are normal atoms or open/end pairs.
And that rule is not limited to %(align).

I am flexible with the terminology, but the point is that I think
the quoting rules are better be specified _outside_ the description
of a particular atom, but as a general rule.

> diff --git a/builtin/tag.c b/builtin/tag.c
> index 9fa1400..f55dfda 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -43,8 +43,8 @@ static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting, con
>  
>  	if (!format) {
>  		if (filter->lines)
> -			format = to_free = xstrfmt("%%(align:15,left)%%(refname:short)%%(end) %%(contents:lines=%d)",
> -						   filter->lines);
> +			format = to_free = xstrfmt("%%(align:15,left)%%(refname:short)%%(end) "
> +						   "%%(contents:lines=%d)", filter->lines);

This line still looks overlong.  Would it help to stop spelling this
as a double "a = b = overlong expression" assignment?

>  	/*
>  	 * Perform quote formatting when the stack element is that of
> -	 * a modifier atom and right above the first stack element.
> +	 * a supporting atom. If nested then perform quote formatting
> +	 * only on the topmost supporting atom.
>  	 */
>  	if (!state->stack->prev->prev) {
>  		quote_formatting(&s, current->output.buf, state->quote_style);
> @@ -261,6 +262,22 @@ static void end_atom_handler(struct atom_value *atomv, struct ref_formatting_sta
>  	pop_stack_element(&state->stack);
>  }
>  
> +static int match_atom_name(const char *name, const char *atom_name, const char **val)
> +{
> +	const char *body;
> +
> +	if (!skip_prefix(name, atom_name, &body))
> +		return 0; /* doesn't even begin with "atom_name" */
> +	if (!body[0] || !body[1]) {
> +		*val = NULL; /* %(atom_name) and no customization */
> +		return 1;
> +	}

This if condition is puzzling.  !body[0] would mean the name was
exactly atom_name, which is what you want to catch.

But the other part does not make any sense to me.  what does
(body[0] != '\0' && !body[1]) mean?  atom_name asked for was "align"
and name was "aligna"?  That is not "%(align) and no customization".

> +	if (body[0] != ':')
> +		return 0; /* "atom_namefoo" is not "atom_name" or "atom_name:..." */

This one makes sense to me.

> +	*val = body + 1; /* "atomname:val" */

Spell that "atom_name:val" perhaps?

  parent reply	other threads:[~2015-09-07  6:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-05 18:52 [PATCH v16 00/14] port tag.c to use ref-filter APIs Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 01/14] ref-filter: move `struct atom_value` to ref-filter.c Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 02/14] ref-filter: introduce ref_formatting_state and ref_formatting_stack Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 03/14] utf8: add function to align a string into given strbuf Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 04/14] ref-filter: introduce handler function for each atom Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 05/14] ref-filter: introduce match_atom_name() Karthik Nayak
2015-09-06 19:52   ` Eric Sunshine
2015-09-07 18:07     ` Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 06/14] ref-filter: implement an `align` atom Karthik Nayak
2015-09-06 20:10   ` Eric Sunshine
2015-09-07 18:26     ` Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 07/14] ref-filter: add option to filter out tags, branches and remotes Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 08/14] ref-filter: add support for %(contents:lines=X) Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 09/14] ref-filter: add support to sort by version Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 10/14] ref-filter: add option to match literal pattern Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 11/14] tag.c: use 'ref-filter' data structures Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 12/14] tag.c: use 'ref-filter' APIs Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 13/14] tag.c: implement '--format' option Karthik Nayak
2015-09-05 18:52 ` [PATCH v16 14/14] tag.c: implement '--merged' and '--no-merged' options Karthik Nayak
2015-09-06 18:49 ` [PATCH v16 00/14] port tag.c to use ref-filter APIs Matthieu Moy
2015-09-06 19:16   ` Karthik Nayak
2015-09-07  6:33 ` Junio C Hamano [this message]
2015-09-07  6:42   ` Matthieu Moy
2015-09-07 13:56   ` Karthik Nayak
2015-09-07 14:05     ` Matthieu Moy
2015-09-08  5:43       ` Karthik Nayak
2015-09-08 18:20       ` Junio C Hamano
2015-09-09 17:37         ` Karthik Nayak
2015-09-09 19:18           ` Junio C Hamano
2015-09-08 18:20     ` Junio C Hamano

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=xmqqh9n6agcf.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --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.
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.