From: Junio C Hamano <gitster@pobox.com>
To: "Jean-Noël AVILA" <jn.avila@free.fr>
Cc: "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] doc: git-clone fix discrepancy between asciidoc and asciidoctor
Date: Mon, 22 Jul 2024 09:39:47 -0700 [thread overview]
Message-ID: <xmqqplr5e5yk.fsf@gitster.g> (raw)
In-Reply-To: <8404759.T7Z3S40VBb@cayenne> ("Jean-Noël AVILA"'s message of "Sun, 21 Jul 2024 15:08:46 +0200")
Jean-Noël AVILA <jn.avila@free.fr> writes:
> Sorry for not being clear. Indeed I was wrong, Asciidoc.py also has this role
> management behavior for any other inline markup (++, _, *, ^, ~) except for
> back-quoted text.
>
>> How about phrasing it more like so?
>>
>> Writing a string inside [square brackets], immediately followed
>> by a string inside `a pair of back quotes`, causes asciidoctor
>> to eliminate the string inside [square brackets], because it is
>> a syntax to trigger a "generalized role" feature, which we do
>> not care about in the context of the synopsis section here.
>>
>> Work it around by inserting an otherwise no-op {empty} string to
>> forbid asciidoctor from triggering that feature here. AsciiDoc
>> is not affected negatively by this additional empty string.
>>
>
> OK, but let's get rid of the "generalized role" stuff, then.
I agree it is not relevant what the feature is called, as that is
something we did not want to trigger and take advantage of.
It still is necessary to mention the fact that [strings] are eaten
by us unknowingly triggering the feature.
> While doing the styling of synopsis, I tried to be smarter than that. There
> are basically 3 semantic entities in the grammar:
>
> * the _<placeholders>_ in italic
> * the `keywords`, in monospace
> * the grammar signs: [, ], |, ..., (, ), etc. These signs are not typeset.
>
> Setting everything in monospace would mix keywords and grammar.
>
> With this schema in mind, I don't find difficult to understand how the synopsis
> is written (putting aside the {empty} hack). Fair enough, this is more
> difficult than just plain text, but the aim is still to get decent output.
Thanks.
It appears that asciidoctor considers `monospaced` that results in
<code>...</code> is a bad match in the SYNOPSIS section
cf. https://lore.kernel.org/git/xmqqsew3hdmv.fsf@gitster.g/
but we should be able to sort it out.
next prev parent reply other threads:[~2024-07-22 16:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-20 17:34 [PATCH] doc: git-clone fix discrepancy between asciidoc and asciidoctor Jean-Noël Avila via GitGitGadget
2024-07-20 23:16 ` Junio C Hamano
2024-07-20 23:23 ` Junio C Hamano
2024-07-21 13:08 ` Jean-Noël AVILA
2024-07-22 16:39 ` Junio C Hamano [this message]
2024-07-23 11:06 ` Jean-Noël Avila
2024-07-23 15:52 ` Junio C Hamano
2024-07-23 17:44 ` Junio C Hamano
2024-07-23 17:47 ` Eric Sunshine
2024-07-23 18:04 ` 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=xmqqplr5e5yk.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=jn.avila@free.fr \
/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).