Daniel Shahaf wrote:
> Gabriela Gibson wrote on Mon, Jun 10, 2013 at 23:39:45 +0100:
>> On 6/10/13, Daniel Shahaf <danielsh_at_elego.de> wrote:
>> >> ----------† ****† ------------
>> >> + How does this parse "%%%f1%"? Is "%%f1%%" an error?
>> >> %%%f1% becomes %%f1% and %%f1%% becomes %f1%%, neither is an error.
>> >> However, %f1%% is parsed out as sub%, also, +%f1% ends up as +sub.
>> > I'm not sure I understand.† I expect %%%f1% to become %sub and %f1%% to
>> > be either an error or sub%.† Is that what is implemented?
>> No.† We sub only %f1% where we find it, but if it's escaped with
>> one or more %'s, we eat exactly one of those instead, so %%%f1% becomes
> That's not the behaviour I would expect.† What I would expect is what I
> mentioned in my question: that the string is parsed left-to-right, and
> whenever an % is seen, the next character is either % in which case a
> literal % is emitted, or 'f1%' (or one of the other five replaceables)
> in which case it is replaced; if it is anything else, the behaviour is
> undefined / not promised.
>> %f1%% becomes sub% as per request by Julian Foad, because some
>> diff clients accept syntax like +sub and sub+ (so, you'd use
>> +%f1% and %f1%+ respectively to get that).
> Okay.† I would have expected '%f1%%%' were required to get 'sub%', and
> leave the case of a 'foobar%' (and '%f1%%') as undefined behaviour.
> What do others think about these %-escaping issues?
There are lots of variable-substitution (or 'interpolation') schemes in the world already -- please don't invent another one.† Choose an existing scheme, look up the spec on the Internet and reference it, and then implement (the relevant parts of) it.
If there's a scheme that we're already using in Subversion, that would be a good choice.† Is there one?† If not, I don't much like the Windows '%foo%' scheme because it's rather irregular compared to others, but if that's what we want to use then I guess that's OK with me, but again, find the spec on the Internet and refer to that.
Received on 2013-06-11 10:48:07 CEST