git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/2] doc: git-checkout: trivial callout cleanup
Date: Thu, 27 Apr 2023 16:09:32 -0600	[thread overview]
Message-ID: <644af29c8526c_7f4f2945f@chronos.notmuch> (raw)
In-Reply-To: <20230425061029.GA4015844@coredump.intra.peff.net>

Jeff King wrote:
> On Mon, Apr 24, 2023 at 05:02:25PM -0700, Junio C Hamano wrote:
> 
> > Felipe Contreras <felipe.contreras@gmail.com> writes:
> > 
> > > No, it's for the formatting machinery.
> > >
> > > The fact that both asciidoc and asciidoctor happen to understand our quircky
> > > formatting in this particualr situation doesn't mean it isn't quirky.
> > >
> > > In this particular case the parsers do understand what we are trying to do,
> > > because we just just pepper list continuations (`+`) everywhere and it happens
> > > to work.
> > 
> > I'll stop at pointing out that the first "no" sounds much stronger
> > than the text that tries to substantiate it, which says that the
> > machinery works fine without the changes.
> > 
> > > This discrepancy confused Jeff in [1].
> > 
> > And this is a good reason to add this change for humans.
> 
> Since I'm being used as the example, I'd like to point that I think this
> is somewhat tangential to what actually confused me there.
> 
> What confused me in that earlier message was that having "+" as the
> continuation between a code-block and its call-out list is odd, since
> "+" is about continuing a list item.

Indeed.

> It happens to work because we're in a larger list item,

No, there's only one list item, but yes, it works when the callout is inside
one.

The `+` is continuing the list item the callout list is part of, it's not part
of the callout.

> but it breaks when you put the two of them in their own block (which is the
> part that got me).

You only need to put one, but when you do, the `+` doesn't belong there as it's
not part of the callout.

> Using just a blank line between the code block and the call-out list
> (instead of the "+") works for asciidoc (it is happy to keep the two
> together) but not asciidoctor (it ends the outer ordered list before
> starting the callout list).

I don't know what you mean.

These are three paragraphs:

  foo

  bar

  roo

These are two paragraphs inside a list item with continuations:

  1. foo
  +
  bar
  +
  roo

These are three paragraphs inside a list item with an open block:


  1. foo
  +
  --
  bar
  
  roo
  --

If you are inside an open block, you don't need the list continuations (`+`).

Therefore a callout inside an open block inside a list item does not need continuations:

  1. foo
  +
  --
  ----
  line 1 <1>
  line 2 <2>
  ----

  <1> callout 1

  <2> callout 2
  --

Just like a callout outside a list item:

  ----
  line 1 <1>
  line 2 <2>
  ----

  <1> callout 1

  <2> callout 2

It's only a callout inside a list item with no open block that needs
continuations, just like any other paragraph:

  1. foo
  +
  ----
  line 1 <1>
  line 2 <2>
  ----
  +
  <1> callout 1
  +
  <2> callout 2

> So the second hunk in the patch, to drop the extra continuation between
> the code block and the callout, makes perfect sense to me.
> 
> The first hunk seems less obviously good to me.

I don't see why: it's exactly the same change: removing an unnecessary space.

Except that space is represented with a `+` inside a list item.

> We might say that it is good to always
> stick the callout list directly adjacent to the associated code block,
> since it does matter in other cases.

I'd say that is good.

> But dropping the blank lines between the paragraph-sized callout blocks makes
> the source less readable,

That is a value judgement. It may be less readable to you, I disagree.

I would expect the subsequent callout blocks as close to the listing block they
refer to as possible.

> and empty lines between list elements are a pretty normal thing in asciidoc.

Usually, yeah when these list elements are independent, but callout elements
are not independent.

To me this is perfectly readable:

  This is a simple example in sh:

  ----
  #!/bin/sh          <1>
  echo 'hello world' <2>
  ----
  <1> Shebang
  <2> "echo" prints

  This is a simple example in Ruby:

  ----
  #!/usr/bin/env ruby <1>
  puts 'hello world' <2>
  ----
  <1> Standard shebang
  <2> "puts" puts a string

Put spaces on the callouts, and it's the exact opposite:

  This is a simple example in sh:

  ----
  #!/bin/sh          <1>
  echo 'hello world' <2>
  ----

  <1> Shebang

  <2> "echo" prints

  This is a simple example in Ruby:

  ----
  #!/usr/bin/env ruby <1>
  puts 'hello world'  <2>
  ----

  <1> Standard shebang

  <2> "puts" puts a string

Cheers.

-- 
Felipe Contreras

  reply	other threads:[~2023-04-27 22:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18  7:00 [PATCH 0/2] doc: git-checkout: trivial style improvements Felipe Contreras
2023-04-18  7:00 ` [PATCH 1/2] doc: git-checkout: trivial callout cleanup Felipe Contreras
2023-04-19 19:37   ` Junio C Hamano
2023-04-24 13:28     ` Felipe Contreras
2023-04-25  0:02       ` Junio C Hamano
2023-04-25  6:10         ` Jeff King
2023-04-27 22:09           ` Felipe Contreras [this message]
2023-05-02 10:18             ` Jeff King
2023-05-02 16:05               ` Felipe Contreras
2023-05-03  6:09               ` Junio C Hamano
2023-05-03 13:46                 ` Felipe Contreras
2023-05-03 17:44           ` Junio C Hamano
2023-04-27 21:30         ` Felipe Contreras
2023-04-18  7:00 ` [PATCH 2/2] doc: git-checkout: reorganize examples Felipe Contreras
2023-04-19 19:37   ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=644af29c8526c_7f4f2945f@chronos.notmuch \
    --to=felipe.contreras@gmail.com \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).