From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
Karthik Nayak <karthik.188@gmail.com>,
Git List <git@vger.kernel.org>
Subject: Re: [PATCH v5 02/12] ref-filter: use strbuf_split_str_omit_term()
Date: Wed, 17 Feb 2016 09:50:30 -0800 [thread overview]
Message-ID: <xmqqio1njkex.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160217003259.GD1187@sigill.intra.peff.net> (Jeff King's message of "Tue, 16 Feb 2016 19:32:59 -0500")
Jeff King <peff@peff.net> writes:
> On Tue, Feb 16, 2016 at 04:28:10PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > On Tue, Feb 16, 2016 at 04:12:08PM -0800, Junio C Hamano wrote:
>> >
>> >> > To be honest, though, I am now on the fence, considering the possible
>> >> > whitespace issue.
>> >>
>> >> Certainly not having to see s[0]->buf over and over is a huge win ;-).
>> >>
>> >> Is the "whitespace issue" a big deal? Does it involve more than a
>> >> similar sibling to string_list_split() that trims the whitespace
>> >> around the delimiter (or allows a regexp as a delimiter "\s*,\s*")?
>> >
>> > I think that solution would work (and IMHO would actually be preferable
>> > to the split-then-trim that strbuf_split does). But it does mean writing
>> > new code.
>>
>> True, but only when we decide to support trimming the whitespace,
>> which can come later.
>>
>> I do not even know if it is wise to accept %(align:position=left, width=4)
>> when %(align:position=left,width=4) would do the job just fine.
>
> Yeah, it was mostly just about being friendly to the user. But if nobody
> is complaining, it may not even be worth worrying about.
I was more worried about the possibility that we may have to support
values with leading or trailing whitespaces in the future.
0. %(align:position=left,width=4)
1. %(align:position=left, width=4)
2. %(align: position =left, width =4)
3. %(align: position = left, width = 4)
4. %(align: position = left , width = 4)
We can probably accept 1. without ambiguity, and probably 2., too.
These examples are about keys with possible leading or trailing
whitespaces, and it is unlikely that we need to support them.
To those who do not think carefully themselves, however, going from
1 & 2 that are handlable (and some might even argue that 1. is
easlier to read) to 3 & 4 will not appear as a big syntax-breaking
leap. But 3 & 4 are; these need disambiguation rule on the value
side (we either introduce quoting, declare no values can have
leading or trailing whitespaces, etc.).
That is why I suggested not to even accept 1. to avoid the slipperly
slope.
next prev parent reply other threads:[~2016-02-17 17:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 19:00 [PATCH v5 00/12] ref-filter: use parsing functions Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 01/12] strbuf: introduce strbuf_split_str_omit_term() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 02/12] ref-filter: use strbuf_split_str_omit_term() Karthik Nayak
2016-02-16 19:22 ` Jeff King
2016-02-16 19:23 ` Jeff King
2016-02-16 20:12 ` Eric Sunshine
2016-02-16 20:49 ` Jeff King
2016-02-16 21:09 ` Eric Sunshine
2016-02-16 22:34 ` Jeff King
2016-02-16 22:49 ` Eric Sunshine
2016-02-16 23:18 ` Jeff King
2016-02-17 0:12 ` Junio C Hamano
2016-02-17 0:22 ` Jeff King
2016-02-17 0:28 ` Junio C Hamano
2016-02-17 0:32 ` Jeff King
2016-02-17 17:50 ` Junio C Hamano [this message]
2016-02-17 17:04 ` Karthik Nayak
2016-02-17 17:39 ` Eric Sunshine
2016-02-17 18:07 ` Karthik Nayak
2016-02-17 18:17 ` Eric Sunshine
2016-02-17 18:21 ` Karthik Nayak
2016-02-17 16:58 ` Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 03/12] ref-filter: bump 'used_atom' and related code to the top Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 04/12] ref-filter: introduce struct used_atom Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 05/12] ref-filter: introduce parsing functions for each valid atom Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 06/12] ref-filter: introduce color_atom_parser() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 07/12] ref-filter: introduce parse_align_position() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 08/12] ref-filter: introduce align_atom_parser() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 09/12] ref-filter: align: introduce long-form syntax Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 10/12] ref-filter: introduce remote_ref_atom_parser() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 11/12] ref-filter: introduce contents_atom_parser() Karthik Nayak
2016-02-16 19:00 ` [PATCH v5 12/12] ref-filter: introduce objectname_atom_parser() 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=xmqqio1njkex.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=peff@peff.net \
--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.