All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fernando Ramos <greenfoo@u92.eu>
To: Philippe Blain <levraiphilippeblain@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com, davvid@gmail.com,
	sunshine@sunshineco.com, seth@eseth.com,
	rogi@skylittlesystem.org
Subject: Re: [PATCH v6 3/3] vimdiff: add tool documentation
Date: Sun, 27 Mar 2022 23:10:52 +0200	[thread overview]
Message-ID: <YkDS3CJEPYpzRoVG@zacax395.localdomain> (raw)
In-Reply-To: <001d3ecd-e1bd-39f4-5123-4a8b1bd1b5a8@gmail.com>

> > +mergetool.{n,g,}vimdiff.layout::
> > +	The vimdiff backend uses this variable to control how its split
> > +	windows look like.  See BACKEND SPECIFIC HINTS section of
> > +	linkgit:git-mergetool[1] for details.
> > +
> 
> I generated the man page for 'git-mergetool' and this bit is included in the 
> Configuration section, that's great. However, it feels a little weird to read
> "see BACKEND SPECIFIC HINTS section of linkgit:git-mergetool[1]" there, since
> that's the help page I'm already reading. So maybe it would be nice to use an
> Asciidoc 'ifndef::git-mergetool[]' directive here to hide the "of linkgit:git-mergetool[1]"
> bit if the current page is git-mergetool[1] ?

Good call. I tried this:

    mergetool.{n,g,}vimdiff.layout::
    	The vimdiff backend uses this variable to control how its split
    	windows look like.  See BACKEND SPECIFIC HINTS section
    ifndef::git-mergetool[] 
    	(on linkgit:git-mergetool[1])
    endif::[]
    	for details.

...does it look good?

I'm asking because I ran "make doc" and the generated man page always contains
the extra piece. When are those asciidoc directives processed? Should two
versions of the same man page be generated?


> This whole section above needs some indentation work to format nicely in Asciidoc/
> Asciidoctor. I've fixed it and will send a 'fixup' patch as a reply.

Thanks! I will include your patch in v7


> This is OK, but adds a lot of lines to the output. Maybe we could display the help
> on the same line ? Something like:
> 
> $ ./bin-wrappers/git mergetool --tool-help
> 'git mergetool --tool=<tool>' may be set to one of the following:
> 		emerge
> 		opendiff
> 		vimdiff		Layout can be customized. Run 'git help mergetool' and check the 'BACKEND SPECIFIC HINTS' section.
> 		vimdiff1	Layout can be customized. Run 'git help mergetool' and check the 'BACKEND SPECIFIC HINTS' section.
> 		# etc.

Yes. It looks nicer in one line. In addition, right now it doesn't offer enough
information to figure out the difference among variants (vimdiff vs vimdiff1 vs
...) that's why I'm going to update v7 to print something like this following
your advice:

    $ ./bin-wrappers/git mergetool --tool-help
    'git mergetool --tool=<tool>' may be set to one of the following:
                    araxis
                    meld
                    vimdiff    Use Vim with a custom layout (see `git help mergetool`'s `BACKEND SPECIFIC HINTS` section).
                    vimdiff1   Use Vim with a 2 panes layout (LOCAL and REMOTE)
                    vimdiff2   Use Vim with a 3 panes layout (LOCAL, MERGED and REMOTE)
                    vimdiff3   Use Vim where only the MERGED file is shown
                    ...


  parent reply	other threads:[~2022-03-27 21:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-27 11:23 [PATCH v6 0/3] vimdiff: new implementation with layout support Fernando Ramos
2022-03-27 11:23 ` [PATCH v6 1/3] " Fernando Ramos
2022-03-27 16:47   ` Philippe Blain
2022-03-27 18:12     ` Fernando Ramos
2022-03-27 21:36   ` Junio C Hamano
2022-03-27 11:23 ` [PATCH v6 2/3] vimdiff: integrate layout tests in the unit tests framework ('t' folder) Fernando Ramos
2022-03-27 21:37   ` Junio C Hamano
2022-03-27 11:23 ` [PATCH v6 3/3] vimdiff: add tool documentation Fernando Ramos
2022-03-27 18:28   ` Philippe Blain
2022-03-27 18:50     ` [PATCH] fixup! " Philippe Blain
2022-03-27 21:10     ` Fernando Ramos [this message]
2022-03-27 21:43       ` [PATCH v6 3/3] " Junio C Hamano
2022-03-27 22:17         ` Fernando Ramos
2022-03-28  4:48   ` Bagas Sanjaya
2022-03-28  5:43     ` Junio C Hamano
2022-03-28 19:19       ` Fernando Ramos

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=YkDS3CJEPYpzRoVG@zacax395.localdomain \
    --to=greenfoo@u92.eu \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=levraiphilippeblain@gmail.com \
    --cc=rogi@skylittlesystem.org \
    --cc=seth@eseth.com \
    --cc=sunshine@sunshineco.com \
    /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.