Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1tVF7f-006heC-SU
	for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jan 2025 19:20:16 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1tVF7f-006rJF-BJ
	for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jan 2025 19:20:15 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1tVF7f-006rJ7-1c
	for pgsql-hackers@lists.postgresql.org; Tue, 07 Jan 2025 19:20:14 +0000
Received: from sss.pgh.pa.us ([68.162.161.243])
	by magus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.96)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1tVF7b-000OTK-1x
	for pgsql-hackers@postgresql.org;
	Tue, 07 Jan 2025 19:20:14 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 507JK9S11499408;
	Tue, 7 Jan 2025 14:20:09 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Melanie Plageman <melanieplageman@gmail.com>
cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Moving the vacuum GUCs' docs out of the Client Connection
 Defaults section
In-reply-to: 
 <CAAKRu_Ymux_RBzp5faSR5-qx1JdM6qS3POVjcWyHbnQjzgmo8g@mail.gmail.com>
References: 
 <CAAKRu_aQUOaMYrcjNuXeSkJtaX9oRUzKP57bsYbC0gVVWS+cbA@mail.gmail.com>
 <1373018.1736213217@sss.pgh.pa.us>
 <CAAKRu_bz3BD4w0jmjfQkckAQE5eb-Ge2a=9Q-HG_rWSTeG_PzA@mail.gmail.com>
 <CAAKRu_Ymux_RBzp5faSR5-qx1JdM6qS3POVjcWyHbnQjzgmo8g@mail.gmail.com>
Comments: In-reply-to Melanie Plageman <melanieplageman@gmail.com>
	message dated "Tue, 07 Jan 2025 12:31:01 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1499406.1736277609.1@sss.pgh.pa.us>
Date: Tue, 07 Jan 2025 14:20:09 -0500
Message-ID: <1499407.1736277609@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/1499407.1736277609%40sss.pgh.pa.us>
Precedence: bulk

Melanie Plageman <melanieplageman@gmail.com> writes:
>> This is my first docs patch that introduces new sections and such, so
>> I'm not sure I got the indentation 100% correct (I, of course, tried
>> to follow conventions).

There really isn't much convention there :-(.  The amount of
indentation used varies wildly across different chunks of our docs.
I'd try to make it look like nearby sections, but those might
themselves be inconsistent.

> Oh, one thing I forgot to say. Though I increased the indentation of
> some of the subsections that I moved, I didn't rewrap the lines
> because they were already not wrapped to 78. I can do this, but I
> can't tell from the existing docs what text width the paragraphs of
> text are supposed to be wrapped to.

If you're moving the text anyway, I'd rewrap it to something less than
80 columns.  Again, there's not a lot of uniformity about exactly how
much less.  I frequently use 74-column width for new docs text, to
leave some room for minor adjustments without having to rewrap;
but I don't think other people follow that rule.

A lot of the existing violations of 80-column right margin come from
when we switched to XML rules and had to fill out abbreviated closing
tags ("</>") to full tags ("</foo>").  That was done with some more or
less automated conversion that didn't do anything about rewrapping
lines that it made too long.  I think that choice was fine, because
it reduced the size of the diff.  But if you're rewriting or moving a
para, that's a good time to clean things up by rewrapping it; it'll
all be new according to "git blame" anyway.

			regards, tom lane