patchrevisions.txt: expand tabs to spaces in diagram

The diagram renders fine in AsciiDoc before and after this patch. Asciidoctor, on the other hand, ignores the tabs entirely, which results in different indentation for different lines. The graph illustration earlier in the document already uses spaces instead of a tab.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
Can be seen at the end of https://git-scm.com/docs/gitrevisions

 Documentation/revisions.txt | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

Martin Ågren <martin.agren@gmail.com> writes:

Ouch. We might want to teach Documentation/.gitattributes that indent-with-tab is unwelcome in that directory, after making this fix (and possibly similar ones to other files).

On 2 May 2018 at 06:50, Junio C Hamano <gitster@pobox.com> wrote:

I actually grepped around a little for a leading tab, to see if I could immediately spot any similar issues. But there are tons of tabs here (about 13000). Most of them work out just fine, e.g., in the OPTIONS, where we tab-indent the descriptions.

So while we could try to move away from leading tabs in Documentation/, it would be a huge undertaking. Any kind of "do it while we're nearby" approach would take a long time to complete. And a one-off conversion would probably be a horrible idea. ;-)

I just noticed another difference in how the tabs are handled. In git-add.txt, which I just picked at random, the three continuation lines in the synopsis indent differently in AsciiDoc (which indents them more than in the .txt) and Asciidoctor (which indents them less than in the .txt). To me, this is more of a "if I didn't sit down and compare the two outputs, I would never think about these indentations -- they're both fine".

So it might be that the only places where leading tabs really matter is this kind of diagrams. Maybe we have a handful such bugs lingering among the 13000 tab-indented lines...

Martin

On Wed, May 02, 2018 at 08:20:54AM +0200, Martin Ågren wrote:

I took a look at this. Asciidoctor does seem to have some weird ideas about tabs, but I think how it's handling this is converting them to spaces, which makes sense if you're working with HTML or XML (which do some bizarre things with tabs).

However, it's not converting them to 8 spaces, which is really what we want here. We can help both AsciiDoc and Asciidoctor do the right thing here (and keep our 8-space tabs) by enclosing the diagram in a block like so:

[literal]
--
   Args   Expanded arguments    Selected commits
   D                            G H D
   D F                          G H I J D F
   ^G D                         H D
   ^D B                         E I J F B
   ^D B C                       E I J F B C
   C                            I J F C
   B..C   = ^B C                C
   B...C  = B ^F C              G H D E B C
   B^-    = B^..B
	  = ^B^1 B              E I J F B
   C^@    = C^1
	  = F                   I J F
   B^@    = B^1 B^2 B^3
	  = D E F               D G H E F I J
   C^!    = C ^C^@
	  = C ^C^1
	  = C ^F                C
   B^!    = B ^B^@
	  = B ^B^1 ^B^2 ^B^3
	  = B ^D ^E ^F          B
   F^! D  = F ^I ^J D           G H D F
--

and using the tabsize=8 attribute when invoking Asciidoctor. I can send a patch tomorrow which does this, which I think may be a bit nicer than having to give up tabs.

Thoughts?

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Yeah, trying to forbid indent-with-tab has been shown to be unworkable so even if we tried to give up tabs, it is likely we would break it by mistake. Allowing indent-with-tab and ask the tool to do the right thing is obviously the right direction.

Thanks.

Asciidoctor expands tabs at the beginning of a line. However, it does not expand them into 8 spaces by default. Since we use 8-space tabs, tell Asciidoctor that we want 8 spaces by setting the tabsize attribute. This ensures that our ASCII art renders properly.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 Documentation/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

When creating a literal block from an indented block without any sort of delimiters, Asciidoctor strips off all leading whitespace, resulting in a misrendered chart. Use an explicit literal block to indicate to Asciidoctor that we want to keep the leading whitespace.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
A future direction we could go here would actually be to turn this into
a table, which might render more acceptably in all forms.  But I think
this patch provides a useful improvement and we can switch to a table
later if desired.

 Documentation/revisions.txt | 2 ++
 1 file changed, 2 insertions(+)

On 6 May 2018 at 22:42, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Excellent. These two patches fix my original problem and seem like the obviously correct approach (in hindsight ;-) ). I wonder if the diagrams earlier in the file should be tackled also. Right now, one has a huge number of dots instead of the four you added; the other has none. They do render fine though, so that'd only be about consistency in the original .txt-file.

On Mon, May 07, 2018 at 06:11:43AM +0200, Martin Ågren wrote:

Yeah, the number of dots has to be at least four, but can be any matching number.

Since this patch fixes the present issue, I'd like to leave it as it is and run through a cleanup series a bit later that catches all the literal indented blocks and marks them explicitly to avoid this issue in the future.

On 8 May 2018 at 03:13, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Sounds like a plan. :-) As noted elsewhere, I have no immediate idea how to identify which of the 13000 tab-indented lines are really part of diagrams and ascii-art. Counting the number of spaces? Anyway, thanks for this mini-series.

Martin

On Tue, May 08, 2018 at 08:31:10PM +0200, Martin Ågren wrote:

I have an utterly terrible Ruby one-liner which I wrote in a few minutes. It has some false positives, but not enough that I'd mind sorting through them.

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Wonderful.  Thanks.