groff
[Top][All Lists]
Advanced

[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>.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]