From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DAF22A0562; Tue, 4 May 2021 13:56:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5680140147; Tue, 4 May 2021 13:56:57 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id A79C140141 for ; Tue, 4 May 2021 13:56:55 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F348D12FA; Tue, 4 May 2021 07:56:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 04 May 2021 07:56:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= zlhRplMqA8EhiVzTaDrkl5csPwj1cCb4QO/WZ2GKdj8=; b=qVBuh5VA09F3grSq Drawgkj5Y98xfDASl+j5WVbUXQkqqKo3QQxoqqn9x5saZXq88bXh8e37ldHZnPSK /VwIAmr2MWwJLgqrddAqGcNJ+koSQdyuq/hfu+zoIUQkkV6SVO1auVxORBDxZvoD q9uHGGJFUNnrDSRE48AvjgXmGFvDMTUIX9/DEg8Dp+R9zFrGm+AD20sHlMU3umgI X7E/lzow7kL/CLOKPFm+f/FahfFqR1Zu1CRgdGo1MFdh2GNbCRo/oknzk0ncM8sy KzfPiQLsyRgbrBE7AW81IMciGFsHpx5PzFeIzUUmHviyWPHKoyAYh77XJSeuEmI2 ySY9hQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=zlhRplMqA8EhiVzTaDrkl5csPwj1cCb4QO/WZ2GKd j8=; b=HlrK43Q2yGuX5+qQHXeezQ8Zqf4eFGS6dBfcxUyB8Urz55nDBSFzezLDD JitoeOCxEgFiRU7FA0PYhkqJYafJVIiLVbyM3Oswaki49Sqcb2pkv3N3jVlpMY6p F64zTl6uhpguWyURI1nU9aaWtjNMOkYSv5m94SjISmhP2AKZnIPV3jZqC7IffktN UDOYvOMfuI7M4Z/2n5LinMNrPuY/Tbqcy4j45GIaZhesAQbEGbqmBozrWjXqRgSh kreehcuvOYeaGy3pBzBPHr/8/2b28j3zJ95Jz8wu9AFgyr92h4sBF0DBB1VjVnpM AtzjPjNNU08rKEKCp+HReXytSTASg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefiedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 4 May 2021 07:56:50 -0400 (EDT) From: Thomas Monjalon To: Conor Walsh , "Burakov, Anatoly" , Ferruh Yigit Cc: john.mcnamara@intel.com, david.marchand@redhat.com, bruce.richardson@intel.com, dev@dpdk.org Date: Tue, 04 May 2021 13:56:48 +0200 Message-ID: <3104956.X4MqZOROy4@thomas> In-Reply-To: <27d6ea7a-d7c7-431b-d4a5-f1bc852e3a1f@intel.com> References: <20210421091146.1384708-1-conor.walsh@intel.com> <3962445.YuhGqRbsoE@thomas> <27d6ea7a-d7c7-431b-d4a5-f1bc852e3a1f@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] doc/contributing/documentation: add info about including code X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 04/05/2021 13:15, Ferruh Yigit: > On 5/4/2021 11:44 AM, Thomas Monjalon wrote: > > 04/05/2021 12:35, Ferruh Yigit: > >> On 5/4/2021 10:59 AM, Thomas Monjalon wrote: > >>> 04/05/2021 11:32, Burakov, Anatoly: > >>>> On 03-May-21 10:02 PM, Thomas Monjalon wrote: > >>>>> 21/04/2021 11:11, Conor Walsh: > >>>>>> + The following will include a snippet from the skeleton sample app:: > >>>>>> + > >>>>>> + .. literalinclude:: ../../../examples/skeleton/basicfwd.c > >>>>>> + :language: c > >>>>>> + :start-after: Display the port MAC address. > >>>>>> + :end-before: Enable RX in promiscuous mode for the Ethernet device. > >>>>>> + :dedent: 1 > >>>>> > >>>>> I would prefer indenting the options with 3 spaces > >>>>> to make them aligned with literalinclude. > >>>>> > >>>>> [...] > >>>>>> +* ``start-after`` and ``end-before`` can use any text within a given file, > >>>>>> + however it may be difficult to find unique text within your code to mark the > >>>>>> + start and end of your snippets. In these cases, it is recommended to include > >>>>>> + explicit tags in your code to denote these locations for documentation purposes. > >>>>>> + > >>>>>> + This can be done as follows: > >>>>>> + > >>>>>> + .. code-block:: c > >>>>>> + > >>>>>> + /* #guide_doc: Example feature being documented. */ > >>>>>> + ... > >>>>>> + /* #guide_doc: End of example feature being documented. */ > >>>>> > >>>>> I think we can standardize this usage in a beautiful syntax. > >>>>> My proposal, using the scissor sign: > >>>>> > >>>>> /* Foo bar >8 */ > >>>>> foo(bar); > >>>>> /* 8< End of foo bar */ > >>>>> > >>>>> .. literalinclude:: foobar.c > >>>>> :language: C > >>>>> :start-after: Foo bar >8 > >>>>> :end-before: 8< End of foo bar > >>>>> > >>>>> Another idea: > >>>>> > >>>>> /*~ Foo bar */ > >>>>> foo(bar); > >>>>> /*~ End of foo bar */ > >>>>> > >>>>> .. literalinclude:: foobar.c > >>>>> :language: C > >>>>> :start-after: ~ Foo bar > >>>>> :end-before: ~ End of foo bar > >>>>> > >>>>> Maybe we don't need any markup for the start line and keep it natural: > >>>>> > >>>>> /* Foo bar */ > >>>>> foo(bar); > >>>>> /* end: Foo bar */ > >>>>> > >>>>> .. literalinclude:: foobar.c > >>>>> :language: C > >>>>> :start-after: Foo bar > >>>>> :end-before: end: Foo bar > >>>> > >>>> Not having markup will 1) risk people accidentally "fixing" or otherwise > >>>> modifying comments, and 2) has bigger potential for collisions elsewhere > >>>> in the comments. While these aren't big risks, IMO it should be > >>>> explicitly obvious that a comment is not just a comment but a marker docs. > >>>> > >>>> Having named tags like in the original proposal is the most explicit > >>>> version of the above, which is why i favor it, but i think it's OK to > >>>> have a lighter-weight syntax (e.g. with scissors for example), however i > >>>> don't think it's a good idea to leave things implicit like your last > >>>> suggestion. > >>> > >>> I think the first comment is not only for code extraction, > >>> but also for code reader, that's why I think it's good to keep it natural. > >> > >> +1 to Anatoly's comment, to make it obvious to the reader of the code that the > >> comment is used for documentation purposes and use explicit syntax for it. > > > > So you assume the comment is only for doc extraction? > > I think it can be a real comment, otherwise we'll need to have > > 2 lines: 1 for doc extraction, 1 for code comment. > > > > I see your point, for the cases that there is already a comment before (or > after) the code, will it be too bad to have multiple lines, something like: > > /* Actual comment > * More details > * > * explicit marker */ > > > I think explicit marker has the advantage of: > - Whoever updating the comment will know that it is a marker for the > documentation and be careful on update > - Whoever updating the code between the markers, know that it may be required to > re-visit the relevant documentation and update it because of code change > - Whoever reading the code will know that part is in a documentation, and may be > interested to go and check the relevant documentation > - Whoever reading the code, and not very familiar with DPDK convention, still > can understand what that comment is for and benefit from above I understand these points. But I'm afraid the proposed syntax #guide_doc: is not so obvious for everybody. I'm sure there can be a better syntax.