All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	Conor Walsh <conor.walsh@intel.com>
Cc: john.mcnamara@intel.com, david.marchand@redhat.com,
	ferruh.yigit@intel.com, bruce.richardson@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] doc/contributing/documentation: add info about including code
Date: Tue, 4 May 2021 10:32:26 +0100	[thread overview]
Message-ID: <c1e6b6de-c057-e4ef-f17a-8150ae11f583@intel.com> (raw)
In-Reply-To: <2242028.kHp4AaGxEa@thomas>

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.

-- 
Thanks,
Anatoly

  reply	other threads:[~2021-05-04  9:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21  9:11 [dpdk-dev] [PATCH] doc/contributing/documentation: add info about including code Conor Walsh
2021-04-21 10:21 ` Mcnamara, John
2021-04-21 10:31   ` Thomas Monjalon
2021-04-21 14:17     ` Mcnamara, John
2021-04-21 14:21       ` Thomas Monjalon
2021-04-27  9:54         ` David Marchand
2021-04-27  9:54 ` David Marchand
2021-05-03 21:02 ` Thomas Monjalon
2021-05-04  9:32   ` Burakov, Anatoly [this message]
2021-05-04  9:59     ` Thomas Monjalon
2021-05-04 10:35       ` Ferruh Yigit
2021-05-04 10:44         ` Thomas Monjalon
2021-05-04 11:15           ` Ferruh Yigit
2021-05-04 11:56             ` Thomas Monjalon
2021-05-05 12:02               ` Burakov, Anatoly
2021-05-06 13:50                 ` Walsh, Conor
2021-05-06 16:40 ` [dpdk-dev] [PATCH v2] doc/contributing/doc: " Conor Walsh
2021-05-07  9:54   ` Burakov, Anatoly
2021-05-07 13:15     ` Thomas Monjalon
2021-05-19 21:36   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1e6b6de-c057-e4ef-f17a-8150ae11f583@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=conor.walsh@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=john.mcnamara@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.