[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [groff] 03/07: groff_ms(7): Update table of contents discussion.
From: |
G. Branden Robinson |
Subject: |
Re: [groff] 03/07: groff_ms(7): Update table of contents discussion. |
Date: |
Thu, 7 Oct 2021 00:17:19 +1100 |
User-agent: |
NeoMutt/20180716 |
At 2021-10-02T23:35:30+0100, Keith Marshall wrote:
> On 02/10/2021 19:14, G. Branden Robinson wrote:
> > gbranden pushed a commit to branch master
> > in repository groff.
> >
> > commit 256d165f40d8a630dacc8bcfc749088fa65152fb
> > Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> > AuthorDate: Sat Oct 2 15:33:18 2021 +1000
> >
> > groff_ms(7): Update table of contents discussion.
> >
> > * Say "TC-LEADER" and "TC-MARGIN", not "TC_LEADER" and "TC_MARGIN".
>
> Thanks for catching, and fixing these typos; unfortunately, you appear
> to have missed a couple of instances, which I've now corrected myself.
Whoops! Well, one good turn deserves another.
> > I feel a twinge about the name "TC-MARGIN"...isn't it more of a
> > field width?
>
> Well, it is a field width, yes, but that field (which is designated to
> display a page number) lies within the (extended) right-hand margin of
> the TOC page, (on the premise that the leader extends to this margin).
I put a scratch paragraph after the TOC in doc/ms.ms and I see what you
mean. I had thought you were saying that \n[TC-MARGIN] permitted the
page number to intrude into the right hand margin, but it doesn't; it's
the amount of inset determining where the leaders stop. That makes
sense.
> If you want to name it something else, I'm open to suggestions; we
> would then need to change it in s.tmac, groff_ms.7.man, and
> pdfmark.ms.
Right (...and doc/groff.texi[1] :) ). It's also occurred to me that
we're using two different abbreviations for "table of contents" in our
name spaces: \*[TOC] and the two noted above. That's probably more
important to address than the margin/field-width nomenclature issue.
The best idea I have for now is TOC-PGWIDTH, but I'm uneasy
with because it's not a "page width". We could attack the problem from
the complementary perspective and expose a register for tuning the
length of TOC _entries_, the quantity from which the existing TC-MARGIN
is subtracted. But that seems less useful.
The use case for TC-MARGIN is so that users can tell ms how wide their
widest page number is going to be, and optionally reserve extra space,
is that correct? So for doc/ms.ms I might set it to \w'00' since that
document is well shy of 100 pages.
TOC-PAGENUMBERFIELDWIDTH would communicate adequate information, but
it's much too long. I'll chew on this some more and see if I can come
up with any bright ideas (swords for this Gordian Knot from people on
this list are also welcome).
Regards,
Branden
[1] ...until doc/ms.ms is "done" and I am ready to delete that entire
chapter of our Texinfo manual as planned in
<https://savannah.gnu.org/bugs/index.php?60061>.
signature.asc
Description: PGP signature