Thread (80 messages) 80 messages, 4 authors, 2022-11-21

Re: [PATCH] docs: de-indent first paragraph of gitformat-* to flow the text

From: Jeff King <hidden>
Date: 2022-11-21 18:00:54

On Mon, Nov 21, 2022 at 03:15:50PM +0100, Ævar Arnfjörð Bjarmason wrote:
But the end result of having some paragraphs use "<p>" in the HTML
output, and to have others wrapped in "<pre><code>" doesn't look
nice. The most minimal way to fix this is to de-indent the opening
line of paragraphs that don't start with another formatting
element (e.g. "*" or "-" would already format them as text). Let's do
that.
Is there any reason to just touch the opening line of the paragraphs,
and not change the indent of the whole thing? I understand that doing
the first line is sufficient to convince asciidoc to do what we want,
and the diff is technically fewer lines, but the result is rather
confusing for people who will work on the source in the future.
There's a lot more to fix in these gitformat-* docs (as their
formatting was funny before), but this is a minimal change to fix the
most major issues.
I briefly looked at doc-diff output here. Most of them looked obviously
correct (though since there isn't a lot of context in the doc-diff, it's
sometimes hard to tell), but a few were questionable:
quoted hunk ↗ jump to hunk
@@ -103,7 +103,7 @@ Git index format
 
   Object name for the represented object
 
-  A 16-bit 'flags' field split into (high to low bits)
+A 16-bit 'flags' field split into (high to low bits)
 
     1-bit assume-valid flag
This puts "A 16-bit flags field" at a different indent than the
paragraph before, but I think it is part of a list. It is less indented
than the follow-on paragraph ("1-bit assume-valid flag"), but I think
that is correct, as it is a sub-list of the 16-bit flags.

I know you said that formatting problems remain, and certainly this was
not right before your patch either. But I think your patch makes it
worse, because it pulls the touched line out of the list (and all of the
adjacent parts are still rendered as code blocks, making the structure
even less clear).
quoted hunk ↗ jump to hunk
@@ -114,7 +114,7 @@ Git index format
     12-bit name length if the length is less than 0xFFF; otherwise 0xFFF
     is stored in this field.
 
-  (Version 3 or later) A 16-bit field, only applicable if the
+(Version 3 or later) A 16-bit field, only applicable if the
   "extended flag" above is 1, split into (high to low bits).
 
     1-bit reserved for future
This is the same (it's the same list).
quoted hunk ↗ jump to hunk
@@ -125,16 +125,16 @@ Git index format
 
     13-bit unused, must be zero
 
-  Entry path name (variable length) relative to top level directory
+Entry path name (variable length) relative to top level directory
     (without leading slash). '/' is used as path separator. The special
     path components ".", ".." and ".git" (without quotes) are disallowed.
     Trailing slash is also disallowed.
And I think this is supposed to be part of that same list, too, but now
is de-dented.
quoted hunk ↗ jump to hunk
-    The exact encoding is undefined, but the '.' and '/' characters
+The exact encoding is undefined, but the '.' and '/' characters
     are encoded in 7-bit ASCII and the encoding cannot contain a NUL
     byte (iow, this is a UNIX pathname).
This is supposed to be a continuation of the earlier "Entry path name"
item, but now is at the same top-level. Which is not right, but arguably
is not worse than before your patch.
quoted hunk ↗ jump to hunk
 
-  (Version 4) In version 4, the entry path name is prefix-compressed
+(Version 4) In version 4, the entry path name is prefix-compressed
     relative to the path name for the previous entry (the very first
     entry is encoded as if the path name for the previous entry is an
     empty string).  At the beginning of an entry, an integer N in the
And this one is another top-level part of the list.
quoted hunk ↗ jump to hunk
--- a/Documentation/gitformat-pack.txt
+++ b/Documentation/gitformat-pack.txt
@@ -294,10 +294,10 @@ Pack file entry: <+
 
   - The same trailer as a v1 pack file:
 
-    A copy of the pack checksum at the end of
+A copy of the pack checksum at the end of
     corresponding packfile.
 
-    Index checksum of all of the above.
+Index checksum of all of the above.
These are supposed to be list items of "The same trailer as..." above.
Now they're de-dented, which I think is worse than the state before your
patch.

I don't want to say "we must fix all format problems at once", but I
think in the cases I pointed out that trying to fix the code-block
problem is a losing battle, because the list-like nature is being made
worse. And they probably should remain untouched until somebody is
willing to turn them into actual list elements and continuation markers.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help