From mboxrd@z Thu Jan 1 00:00:00 1970 From: Karthik Nayak Subject: Re: [PATCH v15 05/13] ref-filter: implement an `align` atom Date: Thu, 3 Sep 2015 19:00:18 +0530 Message-ID: References: <1441131994-13508-1-git-send-email-Karthik.188@gmail.com> <1441131994-13508-6-git-send-email-Karthik.188@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Matthieu Moy , Git , Christian Couder To: Junio C Hamano X-From: git-owner@vger.kernel.org Thu Sep 03 15:30:55 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZXUbO-00061L-Ky for gcvg-git-2@plane.gmane.org; Thu, 03 Sep 2015 15:30:55 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753832AbbICNau (ORCPT ); Thu, 3 Sep 2015 09:30:50 -0400 Received: from mail-ob0-f169.google.com ([209.85.214.169]:36115 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753284AbbICNat (ORCPT ); Thu, 3 Sep 2015 09:30:49 -0400 Received: by obqa2 with SMTP id a2so32157918obq.3 for ; Thu, 03 Sep 2015 06:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0jSODkG3JPRlnSiPOapKDMHCCBOHLYu1QMrwro8dmSM=; b=iVPmK03Elf5HWvIIqu/7w2tYqRK6FFa+idACWClXRf28NWHIJl6R9wGXV1kCcWiRsW k8OpIWtMx6rJPjcRmfSq4nO/UMQVtw509cl6gmw6do+UxHXM0jarP81AfR6kWFMmk2KL 66ZjpkjQw9rwf6PB79HrUvicrCYVPFKpSET5/NheSgdE6784oyK/loVOQ10DmTDl8ESu hKSNjKQ6Mf2L9E5XtEsQ+UGrgTiTdcoIdW1dHDkDHgTBd2Q4/FGhHMoG1w++GIPN3s9V LizlrjIO9C5ZaBh3/D5CVYg2Ttjps5kBGWF6S02plExuSzbCfz3BtHflFnwRDys3mUF7 oZCA== X-Received: by 10.182.81.98 with SMTP id z2mr25576102obx.70.1441287048345; Thu, 03 Sep 2015 06:30:48 -0700 (PDT) Received: by 10.182.59.102 with HTTP; Thu, 3 Sep 2015 06:30:18 -0700 (PDT) In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Wed, Sep 2, 2015 at 10:58 PM, Junio C Hamano wrote: > Matthieu Moy writes: > >> Junio C Hamano writes: >> >>> Karthik Nayak writes: >>> >>>> On Wed, Sep 2, 2015 at 8:31 PM, Junio C Hamano wrote: >>>>> Karthik Nayak 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