From: "René Scharfe" <l.s.r@web.de>
To: Jeff King <peff@peff.net>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 3/5] replace strbuf_expand_dict_cb() with strbuf_expand_step()
Date: Tue, 27 Jun 2023 18:24:12 +0200 [thread overview]
Message-ID: <68593128-21e8-a728-719c-632fccf740d6@web.de> (raw)
In-Reply-To: <20230627083526.GA1273865@coredump.intra.peff.net>
Am 27.06.23 um 10:35 schrieb Jeff King:
> On Tue, Jun 27, 2023 at 04:29:02AM -0400, Jeff King wrote:
>
>> Your comment above does make me wonder if strbuf_expand_step() should be
>> quietly handling "%%" itself. But I guess strbuf_expand() doesn't, and
>> your branch.c quote-literal example probably would not want that
>> behavior.
>
> Er, nope, strbuf_expand() does handle "%%" itself. It really feels like
> we'd want strbuf_expand_step() to do so, too, then. Even if we had two
> variants (a "raw" one which doesn't handle "%%" so that branch.c could
> use it, and then another that wrapped it to handle "%%").
strbuf_expand() handles %% and unrecognized placeholders.
We could do that, or move the %% handling to strbuf_expand_literal or
something else. E.g. initially I had a strbuf_expand_default that
handled %% and unrecognized placeholders.
I think it's a good idea to first get used to the loop paradigm by
eschewing the sugary automatic handling and having everything spelled
out explicitly. It's just one more branch. Then we can come up with
a better factoring after a while.
René
next prev parent reply other threads:[~2023-06-27 16:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-17 20:37 [PATCH 0/5] replace strbuf_expand() René Scharfe
2023-06-17 20:40 ` [PATCH 1/5] pretty: factor out expand_separator() René Scharfe
2023-06-17 20:41 ` [PATCH 2/5] strbuf: factor out strbuf_expand_step() René Scharfe
2023-06-19 16:10 ` Taylor Blau
2023-06-20 16:25 ` René Scharfe
2023-06-21 12:26 ` Taylor Blau
2023-06-27 8:26 ` Jeff King
2023-06-27 16:21 ` René Scharfe
2023-06-17 20:42 ` [PATCH 3/5] replace strbuf_expand_dict_cb() with strbuf_expand_step() René Scharfe
2023-06-27 8:29 ` Jeff King
2023-06-27 8:35 ` Jeff King
2023-06-27 16:24 ` René Scharfe [this message]
2023-06-17 20:43 ` [PATCH 4/5] replace strbuf_expand() " René Scharfe
2023-06-27 8:54 ` Jeff King
2023-06-27 16:31 ` René Scharfe
2023-06-27 20:19 ` Jeff King
2023-06-17 20:44 ` [PATCH 5/5] strbuf: simplify strbuf_expand_literal_cb() René Scharfe
2023-06-27 8:57 ` Jeff King
2023-06-27 16:32 ` René Scharfe
2023-06-27 20:21 ` Jeff King
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=68593128-21e8-a728-719c-632fccf740d6@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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).