From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26475 invoked by alias); 1 Dec 2017 00:08:45 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 26462 invoked by uid 89); 1 Dec 2017 00:08:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-0.7 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=tools.=c2, H*f:sk:55018bf, change.=c2, bla?= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Dec 2017 00:08:44 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 04BDB8008D for ; Fri, 1 Dec 2017 00:08:43 +0000 (UTC) Received: from [10.3.116.45] (ovpn-116-45.phx2.redhat.com [10.3.116.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B0C9760852 for ; Fri, 1 Dec 2017 00:08:42 +0000 (UTC) Subject: Re: [PATCH 00/24] Remove TRAD_SYNOPSIS To: newlib@sourceware.org References: <20171130102858.16160-1-yselkowi@redhat.com> <55018bf9-d4c7-3bc8-c75e-da5de770a6d1@LGSInnovations.com> <20171130161106.GB26161@calimero.vinschen.de> <20171130180550.GD26161@calimero.vinschen.de> From: Yaakov Selkowitz Message-ID: Date: Fri, 01 Dec 2017 09:39:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171130180550.GD26161@calimero.vinschen.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0l85xJ7tkfF2vCjTj9DWi11QxmXT0oRPG" X-IsSubscribed: yes X-SW-Source: 2017/txt/msg01213.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0l85xJ7tkfF2vCjTj9DWi11QxmXT0oRPG Content-Type: multipart/mixed; boundary="dw0OSJ0cnEnbkdP6CHC5sdxA8K6810giD"; protected-headers="v1" From: Yaakov Selkowitz To: newlib@sourceware.org Message-ID: Subject: Re: [PATCH 00/24] Remove TRAD_SYNOPSIS References: <20171130102858.16160-1-yselkowi@redhat.com> <55018bf9-d4c7-3bc8-c75e-da5de770a6d1@LGSInnovations.com> <20171130161106.GB26161@calimero.vinschen.de> <20171130180550.GD26161@calimero.vinschen.de> In-Reply-To: <20171130180550.GD26161@calimero.vinschen.de> --dw0OSJ0cnEnbkdP6CHC5sdxA8K6810giD Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: quoted-printable Content-length: 2401 On 2017-11-30 12:05, Corinna Vinschen wrote: > On Nov 30 12:40, Craig Howland wrote: >> On 11/30/2017 11:11 AM, Corinna Vinschen wrote: >>> On Nov 30 10:53, Craig Howland wrote: >>>> On 11/30/2017 05:28 AM, Yaakov Selkowitz wrote: >>>>> This completely removes TRAD_SYNOPSIS and renames ANSI_SYNOPSIS to >>>>> SYNOPSIS throughout Newlib's docuemntation. I'm just not sure about >>>>> the doc tools themselves; should support for both of those names also >>>>> be removed? >>>>> >>>> A thought is to leave them in the doc tools.=C2=A0 Since the tools tre= at SYNOPSIS >>>> and ANSI_SYNOPSIS the same, they'll work the same with or without the >>>> present change.=C2=A0 Leaving in TRAD_SYNOPSIS as something to be igno= red plus >>>> keeping ANSI_SYNOPSIS as working could possibly help out people that h= ave >>>> added their own stuff, not forcing them to make these same changes. >>>> (Probably a very small to non-existent set of people, but it is diffic= ult to >>>> know if there are any or not.)=C2=A0 It doesn't seem to hurt anything = to leave >>>> them, although adding a note that they have been retained for legacy >>>> purposes might be a good idea. >>> Wouldn't it be better in the long run to fail on seeing a TRAD_SYNOPSIS >>> or ANSI_SYNOPSIS and tell the dev to remove the first and to rename the >>> latter? It's not very hard to fix, >>> >> It depends on your point of view.=C2=A0 I agree that it is easy to fix, = but the >> idea of keeping it was thinking that if I happened to have files that >> suddenly became obsolete and I had to spend to to alter the word I would= be >> annoyed at the waste of time:=C2=A0 discover the problem, track down how= to fix >> it, then do it.=C2=A0 Figuring it out would likely be the longest. >=20 > That was the idea: The doc building process should not simply fail but > explain what's wrong and just print a matching message during build: >=20 > "bla bla, outdated, remove TRAD_SYNOPSIS and rename ANSI_SYNOPSIS > to SYNOPSIS, bla, bla" Apparently error messages during doc building are printed to a non-obvious location, meaning these probably wouldn't be seen. Simply removing any mention of these tags apparently causes them to be ignored. Is there a way to raise an error when these tags are found? If there is no simple solution to this, perhaps we should consider this separately from the existing patchset. --=20 Yaakov --dw0OSJ0cnEnbkdP6CHC5sdxA8K6810giD-- --0l85xJ7tkfF2vCjTj9DWi11QxmXT0oRPG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 228 -----BEGIN PGP SIGNATURE----- iHQEARECADQWIQRFYAu5jKh4qpenARn/IK+aZu4flAUCWiCdiBYceXNlbGtvd2l0 ekBjeWd3aW4uY29tAAoJEP8gr5pm7h+UCJ8An3enbZeauA9+BxBF5yRHrW+BK64r AJ9XbHZhPEJeRGujGPfShIzNWc9UfA== =nBzD -----END PGP SIGNATURE----- --0l85xJ7tkfF2vCjTj9DWi11QxmXT0oRPG--