On Wed, Sep 2, 2015 at 10:58 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
>
>> Junio C Hamano <gitster@xxxxxxxxx> writes:
>>
>>> Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>>>
>>>> On Wed, Sep 2, 2015 at 8:31 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>>>> Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>>>>>
>>>>>>>> + die(_("format: `end` atom used without a supporting atom"));
>>>>>>>
>>>>>>> Not a show-stopper, but we may need some wordsmithing for "a
>>>>>>> supporting atom" here; an end-user would not know what it is.
>>>>>>
>>>>>> Probably something like "format: `end` atom should only be
>>>>>> used with modifier atoms".
>>>>>
>>>>> Between "supporting" and "modifier" I do not see much difference,
>>>>> though.
>>>>
>>>> I don't see how we could provide a better message, as %(end) atom
>>>> would be common to various atoms eventually.
>>>
>>> I said "not a show-stopper" without giving a suggestion exactly
>>> because I didn't (and I still don't) think either you or I can come
>>> up with a good wording ;-). That is why the message was Cc'ed to
>>> the list for others to comment.
>>
>> I don't really have a better proposal either. What we really mean is
>> "%(end) requires an atom that requires to be paired with %(end)", but
>> that wouldn't really help. I prefer "supporting" to "modifier":
>> To me, %(color:red) can be called a "modifier" by I wouldn't call %(if)
>> a modifier. "Supporting" is vague, but less misleading to me.
>>
>> Perhaps "corresponding"? (not convinced myself ...)
>
> Yeah, it is like an open and a close parentheses that form a
> matching pair. "%(end) without a corresponding atom" (implying
> "that opened the environment the %(end) attempts to close")?
>
> We'd need to define what an atom is (or "supporting atom" for that
> matter) and explain how nesting works in the documentation anyway,
> and I'd expect we would gain definitions of a few terms we can use
> in this error message.
>
Then I'll just change it to corresponding for now, and probably go back to it
after the series? Maybe work on some documentation at the end of the series.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html