git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jean-Noël AVILA" <jn.avila@free.fr>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [PATCH v2] doc: change the markup of paragraphs following a nested list item
Date: Sat, 04 Oct 2025 19:31:29 +0200	[thread overview]
Message-ID: <2239952.irdbgypaU6@cayenne> (raw)
In-Reply-To: <20251003034134.GA625140@coredump.intra.peff.net>

On Friday, 3 October 2025 05:41:34 CEST Jeff King wrote:
> On Thu, Oct 02, 2025 at 11:11:14PM -0400, Jeff King wrote:
> > which I think is wrong? Looking at the end result with more context, it
> > 
> > is:
> >              refStorage
> >              
> >                  Specify the ref storage format to use. The acceptable
> >                  values are:
> >                  
> >                  •   files for loose files with packed-refs. This is the
> >                  
> >                      default.
> >                  
> >                  •   reftable for the reftable format. This format is
> >                  
> >                      experimental and its internals are subject to
> >                      change.
> >              
> >              Note that this setting should only be set by git-init(1) or
> >              git-clone(1). Trying to change it after initialization will
> >              not work and will produce hard-to-diagnose issues.
> > 
> > So that "Note that..." paragraph is attached to the refStorage
> > definition, and should be indented to the same level as "Specify...".
> > 
> > Even more interesting, I think asciidoc gets this wrong both before and
> > after your patch!
> 
> Sorry, this is incorrect. Rendering with regular asciidoc does produce
> the right output already.
> 
> The patch I showed to drop the extra newline turns that final paragraph
> into a continuation of the second bullet point. So it is wrong for both
> asciidoc (which is already correct) and for asciidoctor (which indents
> too little, but after my proposed patch indents too much).
> 
> That's a little hard to parse, so here's my attempt at showing visually.
> The rendered output before that final paragraph looks something like
> this, with markers 1-3 showing possible indentation levels:
> 
>   refStorage
>       Specify ...
> 
>       •   files ...
> 
>       •   reftable ...
> 
>   (1) a peer of "refStorage" in the definition list
>       (2) a continuation paragraph in the "refStorage" definition
>           (3) a continuation paragraph in the second bullet point
> 
> The paragraph "Note that..." should be at indentation level 2, and
> currently is for both asciidoc and asciidoctor. After your patch it is
> unchanged in asciidoc and at indentation level 1 in asciidoctor.
> 
> My proposed patch (which is garbage) moves it to indentation level 3 in
> both.
> 
> I think to appease both systems we need to put the inner bulleted list
> inside a block. I think that is OK in this case because there is no
> inner block marker to worry about. So:
> 
> diff --git a/Documentation/config/extensions.adoc
> b/Documentation/config/extensions.adoc index 49a7598ca5..aaea8c107f 100644
> --- a/Documentation/config/extensions.adoc
> +++ b/Documentation/config/extensions.adoc
> @@ -55,8 +55,9 @@ For historical reasons, this extension is respected 
regardless of
> the refStorage:::
>  	Specify the ref storage format to use. The acceptable values are:
>  +
> +--
>  include::../ref-storage-format.adoc[]
> -
> +--
>  +
>  Note that this setting should only be set by linkgit:git-init[1] or
>  linkgit:git-clone[1]. Trying to change it after initialization will not
> 
> on top of your patch seems to do the right thing (no change in asciidoc,
> and eliminating the regression from your patch). It's a little gross
> because we are reaching across the include to realize that
> ref-storage-format.adoc contains a list that needs to go into its own
> block. I wonder if asciidoc implicitly opens a new block for an include
> but asciidoctor doesn't. But at any rate, this is the only way I could
> come up with for both to render correctly.
> 
> -Peff


Thank you for cross-checking. This is indeed almost impossible to mechanize 
such testing at the moment.

JN




  parent reply	other threads:[~2025-10-04 17:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-23 18:34 doc: config/extensions.adoc: line continuation syntax error Kristoffer Haugsbakk
2025-09-23 21:08 ` Jean-Noël AVILA
2025-09-24  0:54   ` Jeff King
2025-09-26 19:40     ` [PATCH] doc: change the markup of paragraphs following a nested list item Jean-Noël Avila
2025-09-26 20:54       ` Junio C Hamano
2025-09-27 19:39         ` [PATCH v2] " Jean-Noël Avila
2025-09-28 15:35           ` Junio C Hamano
2025-10-03  3:11           ` Jeff King
2025-10-03  3:41             ` Jeff King
2025-10-03 16:29               ` Junio C Hamano
2025-10-04 17:31               ` Jean-Noël AVILA [this message]
2025-10-10 16:11                 ` Junio C Hamano
2025-10-10 22:23                   ` Jeff King
2025-10-13 15:17                     ` Junio C Hamano

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=2239952.irdbgypaU6@cayenne \
    --to=jn.avila@free.fr \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).