git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jean-Noël AVILA" <jn.avila@free.fr>
To: Johannes Sixt <j6t@kdbg.org>
Cc: "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 4/5] doc: git-diff: apply format changes to diff-generate-patch
Date: Mon, 05 Aug 2024 22:12:08 +0200	[thread overview]
Message-ID: <8448316.NyiUUSuA9g@cayenne> (raw)
In-Reply-To: <5ef4a7bd-3b9f-4e71-9a22-e22012f815ce@kdbg.org>

On Monday, 5 August 2024 07:53:19 CEST Johannes Sixt wrote:
> Am 04.08.24 um 22:05 schrieb Jean-Noël Avila via GitGitGadget:
> > @@ -134,17 +135,18 @@ or like this (when the `--cc` option is used):
> >  
> >  2.   It is followed by one or more extended header lines
> >       (this example shows a merge with two parents):
> > -
> > -       index <hash>,<hash>..<hash>
> > -       mode <mode>,<mode>..<mode>
> > -       new file mode <mode>
> > -       deleted file mode <mode>,<mode>
> >  +
> > -The `mode <mode>,<mode>..<mode>` line appears only if at least one of
> > -the <mode> is different from the rest. Extended headers with
> > +[synopsis]
> > +index <hash>,<hash>`..`<hash>
> > +mode <mode>,<mode>`..`<mode>
> > +new file mode <mode>
> > +deleted file mode <mode>,<mode>
> > ++
> > +The `mode` __<mode>__++,++__<mode>__++..++__<mode>__ line appears only if 
at least one of
> > +the _<mode>_ is different from the rest. Extended headers with
> 
> I've a strong aversion to the formatting that this series applies,
> because it introduces many (IMHO) unnecessary punctuation that
> vandalizes the perfectly readable plain text. And this hunk now shows
> where it goes too far. These lines under the new [synopsis] header just
> aren't syopsis; they are comamnd output. The updated version abuses a
> semantic token to achieve syntactic highlighting.
> 
> To me this series looks too much like "we must adapt to the tool" when
> the correct stance should be "the tool must adapt to us". If the tool
> (one of asciidoc and asciidoctor, I presume) does not cooperate well
> with out documents, then it is the tool that must be changed, not our
> documents.
> 
> I understand that some compromises are needed, but with this extent of
> changes we give in to a sub-par tool too far.
> 
> Just my 2c.
> 
> -- Hannes
> 
> 

Hello,

I was half expecting this kind of reactions. First there are some remarks on 
your remarks.
 
 * You think the markup is unnecessary. To me, it is critical in order to make 
the documentation output a little more meaningful. My experience as a 
translator is that there's a great lack of consistency in the vocabulary, the 
grammar styles, the typesetting and the cross-references of the pages. On top 
of that, they are clearly not user-oriented. Overall, the joke about how 
cryptic the man-pages of Git are is not coming from nowhere. There's no one to 
blame: we are all developers doing our best, but we are not technical writers 
dedicated to this project.
 * The fact that the source of the pages should be "perfectly readable" is a 
moot argument. Fair enough, it is not the objective to make it impossible to 
understand, but in the end, this is not what is consumed: these pages are 
compiled into other formats where the markup has been translated into styling. 
I suspect some writers are not thinking when quoting text, that this is not a 
quotation but an inline formatting command. But this is markup, and sometimes, 
it cannot  be removed of the way.
 * I converted the lines to synopsis because there are placeholders in them. 
These lines are presented as an example but they are neither. This is another 
example of communication impedance,  where the presented text is not what it 
is described as, and requires from the reader to interpret what the writer was 
thinking and forgot to make clear to a newcomer.


As for the "need to adapt to the tool", for block formatting, I tried to get 
something bearable (the synopis style); I'd really like something similar for 
inline formatting but my asciidoc/asciidoctor Fu requires an upgrade in order 
to make it happen. As it seems to be too epidermic, I'll try to cook something 
anyway and keep being open to any proposition.

In the mean time, a proper editor setup (syntax highlighting and fontification 
, two panels with one showing the compiled output) can alleviate your pain. 

JN



  parent reply	other threads:[~2024-08-05 20:12 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-04 20:05 [PATCH 0/5] doc: git diff reformatting Jean-Noël Avila via GitGitGadget
2024-08-04 20:05 ` [PATCH 1/5] doc: git-diff: apply new documentation guidelines Jean-Noël Avila via GitGitGadget
2024-08-05  9:11   ` Patrick Steinhardt
2024-08-05 18:51     ` Jean-Noël AVILA
2024-08-06  6:27       ` Patrick Steinhardt
2024-08-04 20:05 ` [PATCH 2/5] doc: git-diff: apply format changes to diff-options Jean-Noël Avila via GitGitGadget
2024-08-04 20:05 ` [PATCH 3/5] doc: git-diff: apply format changes to diff-format Jean-Noël Avila via GitGitGadget
2024-08-04 20:05 ` [PATCH 4/5] doc: git-diff: apply format changes to diff-generate-patch Jean-Noël Avila via GitGitGadget
2024-08-05  5:53   ` Johannes Sixt
2024-08-05 16:08     ` Junio C Hamano
2024-08-07 20:43       ` [RFC] formatting macro Jean-Noël AVILA
2024-08-12  6:35         ` Johannes Sixt
2024-08-12 15:22           ` Junio C Hamano
2024-08-13 20:42           ` Jean-Noël AVILA
2024-08-05 20:12     ` Jean-Noël AVILA [this message]
2024-08-04 20:05 ` [PATCH 5/5] doc: git-diff: apply format changes to config part Jean-Noël Avila via GitGitGadget
2024-11-11 16:53 ` [PATCH v2 0/5] doc: git diff reformatting Jean-Noël Avila via GitGitGadget
2024-11-11 16:53   ` [PATCH v2 1/5] doc: git-diff: apply new documentation guidelines Jean-Noël Avila via GitGitGadget
2024-11-12  0:48     ` Junio C Hamano
2024-11-12  8:40       ` Jean-Noël Avila
2024-11-12  9:13         ` Junio C Hamano
2024-11-12 18:28           ` Johannes Sixt
2024-11-12 23:01             ` Junio C Hamano
2024-11-13  7:31               ` Johannes Sixt
2024-11-13  8:59               ` Jean-Noël Avila
2024-11-11 16:53   ` [PATCH v2 2/5] doc: git-diff: apply format changes to diff-options Jean-Noël Avila via GitGitGadget
2024-11-12  0:52     ` Junio C Hamano
2024-11-12  9:04       ` Jean-Noël Avila
2024-11-12  9:14         ` Junio C Hamano
2024-11-11 16:53   ` [PATCH v2 3/5] doc: git-diff: apply format changes to diff-format Jean-Noël Avila via GitGitGadget
2024-11-12 18:51     ` Johannes Sixt
2024-11-12 23:03       ` Junio C Hamano
2024-11-13  7:39         ` Johannes Sixt
2024-11-13  8:10       ` Jean-Noël Avila
2024-11-11 16:53   ` [PATCH v2 4/5] doc: git-diff: apply format changes to diff-generate-patch Jean-Noël Avila via GitGitGadget
2024-11-11 16:53   ` [PATCH v2 5/5] doc: git-diff: apply format changes to config part Jean-Noël Avila via GitGitGadget
2024-11-12 18:51     ` Johannes Sixt
2024-11-13  8:12       ` Jean-Noël Avila
2024-11-16 19:36   ` [PATCH v3 0/5] doc: git diff reformatting Jean-Noël Avila via GitGitGadget
2024-11-16 19:36     ` [PATCH v3 1/5] doc: git-diff: apply new documentation guidelines Jean-Noël Avila via GitGitGadget
2024-11-17 14:04       ` Johannes Sixt
2024-11-17 16:44         ` Jean-Noël AVILA
2024-11-18  0:35           ` Junio C Hamano
2024-11-18  0:27         ` Junio C Hamano
2024-11-16 19:36     ` [PATCH v3 2/5] doc: git-diff: apply format changes to diff-options Jean-Noël Avila via GitGitGadget
2024-11-16 19:36     ` [PATCH v3 3/5] doc: git-diff: apply format changes to diff-format Jean-Noël Avila via GitGitGadget
2024-11-16 19:36     ` [PATCH v3 4/5] doc: git-diff: apply format changes to diff-generate-patch Jean-Noël Avila via GitGitGadget
2024-11-16 19:36     ` [PATCH v3 5/5] doc: git-diff: apply format changes to config part Jean-Noël Avila via GitGitGadget
2024-11-18 22:05     ` [PATCH v4 0/5] doc: git diff reformatting Jean-Noël Avila via GitGitGadget
2024-11-18 22:05       ` [PATCH v4 1/5] doc: git-diff: apply new documentation guidelines Jean-Noël Avila via GitGitGadget
2025-03-31  9:37         ` SZEDER Gábor
2025-03-31 12:55           ` [PATCH] doc: fix asciidoctor synopsis processing of triple-dots Jean-Noël Avila
2025-03-31 17:45             ` SZEDER Gábor
2025-03-31 20:30               ` Jean-Noël AVILA
2025-04-01 11:08               ` Jean-Noël Avila
2025-04-01 21:48                 ` Junio C Hamano
2025-04-02  6:49                   ` Jean-Noël Avila
2025-04-07 15:11                     ` Junio C Hamano
2024-11-18 22:05       ` [PATCH v4 2/5] doc: git-diff: apply format changes to diff-options Jean-Noël Avila via GitGitGadget
2024-11-18 22:05       ` [PATCH v4 3/5] doc: git-diff: apply format changes to diff-format Jean-Noël Avila via GitGitGadget
2024-11-18 22:05       ` [PATCH v4 4/5] doc: git-diff: apply format changes to diff-generate-patch Jean-Noël Avila via GitGitGadget
2024-11-18 22:05       ` [PATCH v4 5/5] doc: git-diff: apply format changes to config part Jean-Noël Avila via GitGitGadget
2024-11-26  4:32       ` [PATCH v4 0/5] doc: git diff reformatting Junio C Hamano
2024-11-26  6:55         ` Johannes Sixt
2024-11-26  7:15           ` 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=8448316.NyiUUSuA9g@cayenne \
    --to=jn.avila@free.fr \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=j6t@kdbg.org \
    /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).