From: Eric Sunshine <sunshine@sunshineco.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Matthieu Moy <matthieu.moy@grenoble-inp.fr>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH/RFC 09/10] ref-filter: introduce contents_atom_parser()
Date: Sat, 12 Dec 2015 22:10:16 -0500 [thread overview]
Message-ID: <CAPig+cTbT60cWk+=6EARte68mmQ2xkS5xFgsgh0FbpoueFcBbg@mail.gmail.com> (raw)
In-Reply-To: <1447271075-15364-10-git-send-email-Karthik.188@gmail.com>
On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> Introduce contents_atom_parser() which will parse the '%(contents)'
> atom and store information into the 'used_atom' structure based on the
> modifiers used along with the atom.
>
> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
> ---
> diff --git a/ref-filter.c b/ref-filter.c
> index 802629b..117bbbb 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -42,6 +42,14 @@ static struct used_atom {
> track : 1,
> trackshort : 1;
> } remote_ref;
> + struct {
> + unsigned int subject : 1,
> + body : 1,
> + signature : 1,
> + all : 1,
> + lines : 1,
> + no_lines;
> + } contents;
Same question as patch 8/10: With the exception of non-bitfield
'no_lines', are these 'contents' flags mutually exclusive? If so, an
enum would be a more natural representation than bitfields.
> } u;
> } *used_atom;
> static int used_atom_cnt, need_tagged, need_symref;
> @@ -92,6 +100,29 @@ void remote_ref_atom_parser(struct used_atom *atom)
> +void contents_atom_parser(struct used_atom *atom)
> +{
> + const char * buf;
> +
> + if (match_atom_name(atom->str, "contents", &buf))
> + atom->u.contents.all = 1;
> +
> + if (!buf)
> + return;
Hmm, I'd have placed the blank line after the 'if (!buf) return;'
rather than before it.
> + if (!strcmp(buf, "body"))
> + atom->u.contents.body = 1;
> + else if (!strcmp(buf, "signature"))
> + atom->u.contents.signature = 1;
> + else if (!strcmp(buf, "subject"))
> + atom->u.contents.subject = 1;
> + else if (skip_prefix(buf, "lines=", &buf)) {
> + atom->u.contents.lines = 1;
> + if (strtoul_ui(buf, 10, &atom->u.contents.no_lines))
> + die(_("positive value expected contents:lines=%s"), buf);
> + } else
> + die(_("improper format entered contents:%s"), buf);
Perhaps a more grammatically-friendly error message?
> +}
> +
> static align_type get_align_position(const char *type)
> {
> if (!strcmp(type, "right"))
> @@ -761,20 +786,16 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct obj
> unsigned long sublen = 0, bodylen = 0, nonsiglen = 0, siglen = 0;
>
> for (i = 0; i < used_atom_cnt; i++) {
> - const char *name = used_atom[i].str;
> + struct used_atom *atom = &used_atom[i];
> + const char *name = atom->str;
> struct atom_value *v = &val[i];
> - const char *valp = NULL;
> if (!!deref != (*name == '*'))
> continue;
> if (deref)
> name++;
> if (strcmp(name, "subject") &&
> strcmp(name, "body") &&
> - strcmp(name, "contents") &&
> - strcmp(name, "contents:subject") &&
> - strcmp(name, "contents:body") &&
> - strcmp(name, "contents:signature") &&
> - !starts_with(name, "contents:lines="))
> + !atom->u.contents.all)
> continue;
> if (!subpos)
> find_subpos(buf, sz,
> @@ -784,26 +805,23 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct obj
>
> if (!strcmp(name, "subject"))
> v->s = copy_subject(subpos, sublen);
> - else if (!strcmp(name, "contents:subject"))
> + else if (atom->u.contents.subject)
> v->s = copy_subject(subpos, sublen);
With the disclaimer that I haven't fully digested the existing logic,
is there a reason that you don't also preprocess bare "subject" as you
preprocess "contents:subject"? Isn't "subject" just historic aliases
for "contents:subject"?
A similar observation may be made about "body" and "contents:body",
although I see they mean slightly different things (for, I suppose,
historical reasons).
> else if (!strcmp(name, "body"))
> v->s = xmemdupz(bodypos, bodylen);
> - else if (!strcmp(name, "contents:body"))
> + else if (atom->u.contents.body)
> v->s = xmemdupz(bodypos, nonsiglen);
> - else if (!strcmp(name, "contents:signature"))
> + else if (atom->u.contents.signature)
> v->s = xmemdupz(sigpos, siglen);
> - else if (!strcmp(name, "contents"))
> - v->s = xstrdup(subpos);
> - else if (skip_prefix(name, "contents:lines=", &valp)) {
> + else if (atom->u.contents.lines) {
> struct strbuf s = STRBUF_INIT;
> const char *contents_end = bodylen + bodypos - siglen;
>
> - if (strtoul_ui(valp, 10, &v->u.contents.lines))
> - die(_("positive value expected contents:lines=%s"), valp);
> /* Size is the length of the message after removing the signature */
> - append_lines(&s, subpos, contents_end - subpos, v->u.contents.lines);
> + append_lines(&s, subpos, contents_end - subpos, atom->u.contents.no_lines);
> v->s = strbuf_detach(&s, NULL);
> - }
> + } else /* For %(contents) without modifiers */
Too many blanks following '/*'; downcase 'for' or drop it altogether:
/* bare %(contents) */
> + v->s = xstrdup(subpos);
> }
> }
>
> --
> 2.6.2
next prev parent reply other threads:[~2015-12-13 3:10 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-11 19:44 [PATCH/RFC 00/10] ref-filter: use parsing functions Karthik Nayak
2015-11-11 19:44 ` [PATCH/RFC 01/10] ref-filter: introduce a parsing function for each atom in valid_atom Karthik Nayak
2015-11-23 23:44 ` Eric Sunshine
2015-11-25 12:10 ` Karthik Nayak
2015-11-25 19:41 ` Eric Sunshine
2015-11-26 18:01 ` Karthik Nayak
2015-12-11 22:18 ` Junio C Hamano
2015-12-12 16:05 ` Karthik Nayak
2015-11-11 19:44 ` [PATCH/RFC 02/10] ref-filter: introduce struct used_atom Karthik Nayak
2015-12-01 23:00 ` Eric Sunshine
2015-11-11 19:44 ` [PATCH/RFC 03/10] ref-fitler: bump match_atom() name to the top Karthik Nayak
2015-11-11 19:44 ` [PATCH/RFC 04/10] ref-filter: skip deref specifier in match_atom_name() Karthik Nayak
2015-12-01 23:11 ` Eric Sunshine
2015-12-03 6:34 ` Karthik Nayak
2015-11-11 19:44 ` [PATCH/RFC 05/10] ref-filter: introduce color_atom_parser() Karthik Nayak
2015-12-01 23:27 ` Eric Sunshine
2015-12-03 13:35 ` Karthik Nayak
2015-12-13 6:05 ` Eric Sunshine
2015-12-13 18:46 ` Karthik Nayak
2015-11-11 19:44 ` [PATCH/RFC 06/10] strbuf: introduce strbuf_split_str_without_term() Karthik Nayak
2015-12-02 8:04 ` Eric Sunshine
2015-12-03 18:12 ` Karthik Nayak
2015-12-11 22:31 ` Junio C Hamano
2015-12-12 16:04 ` Karthik Nayak
2015-11-11 19:44 ` [PATCH/RFC 07/10] ref-filter: introduce align_atom_parser() Karthik Nayak
2015-12-02 21:23 ` Eric Sunshine
2015-12-07 17:00 ` Karthik Nayak
2015-11-11 19:44 ` [PATCH/RFC 08/10] ref-filter: introduce remote_ref_atom_parser() Karthik Nayak
2015-12-13 0:53 ` Eric Sunshine
2015-12-13 6:02 ` Karthik Nayak
2015-12-13 6:15 ` Eric Sunshine
2015-12-13 8:32 ` Karthik Nayak
2015-12-13 8:45 ` Eric Sunshine
2015-12-13 8:53 ` Karthik Nayak
2015-11-11 19:44 ` [PATCH/RFC 09/10] ref-filter: introduce contents_atom_parser() Karthik Nayak
2015-12-13 3:10 ` Eric Sunshine [this message]
2015-12-13 4:41 ` Eric Sunshine
2015-12-13 19:36 ` Karthik Nayak
2015-12-13 19:33 ` Karthik Nayak
2015-11-24 21:48 ` [PATCH/RFC 00/10] ref-filter: use parsing functions Jeff King
2015-11-25 12:07 ` Karthik Nayak
2015-11-25 13:44 ` [PATCH/RFC 10/10] ref-filter: introduce objectname_atom_parser() Karthik Nayak
2015-12-13 4:49 ` Eric Sunshine
2015-12-13 19:40 ` Karthik Nayak
2015-12-11 22:49 ` [PATCH/RFC 00/10] ref-filter: use parsing functions Junio C Hamano
2015-12-13 5:40 ` Eric Sunshine
2015-12-13 9:31 ` Karthik Nayak
2015-12-13 21:55 ` Eric Sunshine
2015-12-16 14:45 ` Karthik Nayak
2015-12-14 19:06 ` 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='CAPig+cTbT60cWk+=6EARte68mmQ2xkS5xFgsgh0FbpoueFcBbg@mail.gmail.com' \
--to=sunshine@sunshineco.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karthik.188@gmail.com \
--cc=matthieu.moy@grenoble-inp.fr \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).