From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id 515F8383982F; Fri, 2 Jul 2021 10:31:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 515F8383982F Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3127 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lzGRz-0006FJ-Lm; Fri, 02 Jul 2021 06:31:11 -0400 Date: Fri, 02 Jul 2021 13:31:09 +0300 Message-Id: <83im1tj9ci.fsf@gnu.org> From: Eli Zaretskii To: Martin =?utf-8?Q?Li=C5=A1ka?= Cc: joseph@codesourcery.com, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org In-Reply-To: (message from Martin =?utf-8?Q?Li=C5=A1ka?= on Fri, 2 Jul 2021 11:30:02 +0200) Subject: Re: [PATCH] Port GCC documentation to Sphinx References: <1446990946.2994.192.camel@surprise> <8641dc55-5412-fbd7-bafd-13604311f5ad@suse.cz> <5ffe3e32-ece0-a1b4-1fcf-e35177fa80b5@suse.cz> <87489d9a-44e2-411c-3f3a-534d07e78b95@suse.cz> <0866a0ea-c846-ea5e-ac7a-d1c8f106cc45@suse.cz> <5bb9a10d-f3b9-f16a-7430-bbae2d4978e2@suse.cz> <2f60f602-5d88-7674-9620-2172748664c5@suse.cz> <83a6n8obh4.fsf@gnu.org> <57743e51-04d5-ec2e-b684-54f0321ef0bd@suse.cz> <83pmw3mrcg.fsf@gnu.org> <83k0makvk7.fsf@gnu.org> <56699e91-9e02-102e-4277-af8823cf3145@suse.cz> <83h7hekpi9.fsf@gnu.org> <79939338-7f4f-121c-5fa9-316ae0fc47aa@suse.cz> <838s2qkm2i.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 10:31:13 -0000 > Cc: joseph@codesourcery.com, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org > From: Martin Liška > Date: Fri, 2 Jul 2021 11:30:02 +0200 > > > So the purpose of having the comma there is to avoid having a period > > in the middle of a sentence, which is added by makeinfo (because the > > Info readers need that). Having a comma there may seem a bit > > redundant, but having a period will definitely look like a typo, if > > not confuse the heck out of the reader, especially if you want to use > > these inline cross-references so massively. > > Well, then it's a bug in Makeinfo. No, it isn't a bug in makeinfo. It's a (mis)feature of the Info format: a cross-reference needs to have a punctuation character after it, so that Info readers would know where's the end of the node/anchor name to which the cross-reference points. Info files are largely plain-ASCII files, so the Info readers need help in this case, and makeinfo produces what they need. > >> What type of conversions and style are going to change with conversion to Sphinx? > > > > Anything that is different from the style conventions described in the > > Texinfo manual. We have many such conventions. > > Which is supposed to be here: > https://www.gnu.org/prep/standards/html_node/Documentation.html#Documentation > right? > > I've just the text. About the shortening of section names in a TOC. I couldn't find > it in the GNU Documentation manual. No, there's also a lot of style guidelines in the Texinfo manual itself. Basically, the documentation of almost every Texinfo directive includes some style guidelines, and there are also sections which are pure guidelines, like the nodes "Conventions", "Node Names", "Structuring Command Types", and some others. > >> Again, please show up concrete examples. What you describe is very theoretical. > > > > We've already seen one: the style of writing inline cross-references > > with the equivalent of @ref. We also saw another: the way you > > converted the menus. It is quite clear to me that there will be > > others. So I'm not sure why you need more evidence that this could be > > a real issue. > > As explained, @ref are generated by Makeinfo in a strange way. > About the menus, I was unable to find it.. See the node "Menu Parts" in the Texinfo manual. If you look at other GNU manuals, you will see that it is a de-facto standard to provide most menu items with short descriptions. > > But maybe all of this is intentional: maybe the GCC project > > consciously and deliberately decided to move away of the GNU > > documentation style and conventions, and replace them with whatever > > the Sphinx and RST conventions are? In that case, there's no reason > > for me to even mention these aspects. > > My intention is preserving status quo as much as possible. Well, but you definitely deviated from the status quo, and it sounds like you did that deliberately, without any discussion. > On the other hand, Sphinx provides quite some nice features why I wanted to use it. Which features are those?