Re: Issue in man page ascii.7

[Alejandro Colomar]

Hi Branden!

On 12/5/22 09:15, G. Branden Robinson wrote:
> Hi Alex & Helge,

[...]

> It would be something like this:
>
> -3: # 3 C S c s     3: !  +  5  ?  I  S  ]  g   q   {\n"
> +3: # 3 C S c s     3: !\&  +  5  ?\&  I  S  ]  g   q   {\n"
> -6: & 6 F V f v     6: $  .  8  B  L  V  \\`  j   t   \\(ti\n"
> +6: & 6 F V f v     6: $  .\&  8  B  L  V  \\`  j   t   \\(ti\n"

Thanks!

> [...]
> > And since it's about formatting, please also CC the following in your
> > patch:
> >
> >      CC: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> >      CC: <groff@gnu.org>
>
> No need in this case; I saw it anyway.  :)  (Though please To: me as a
> rule if my feedback/opinion is explicitly desired.)

Sure, I try to do it consistently.  If I Cc you is a "just read it if you want, 
not forced, maybe you're busy and someone else on groff@ picks it up".  :)

> > I can do this later, just for your background this was an old bug in
> > Debian which manpage-l10n worked around:
> >
> > https://bugs.debian.org/692765
>
> This can be done (I see now that my suggestion recapitulates one from
> Colin Watson, in a ticket trail to which I later contributed), but
> what's going on here is actually a GNU tbl(1) bug.
>
> https://savannah.gnu.org/bugs/?61909
>
> "The tbl(1)s from Heirloom Doctools and Unix Version 7 do not supplement
> an ordinary table entry with inter-sentence space, but groff's tbl(1)
> does.
>
> This seems wrong.  This bug is present in groff 1.22.4."
>
> (N.B., the above says *ordinary* table entries.  A text block will
> witness the power of this fully armed and operational formatter^U
> be formatted as was the text prior to the table, which is general means
> it will be filled, supplemented with inter-sentence space, automatically
> hyphenated, adjusted, and broken.)
>
> I didn't bother to try figuring out how far back the bug dates, but it
> seems like the sort that might be 30 years old.
>
> Funnily enough it was just last week that I was whacking on tbl and my
> sense of personal irritation overrode my list of groff 1.23 release
> goals.  So here's the good news.

[...commit log that fixes the bug...]

> It's possible this was overkill.[1]
>
> However, because 1.23.0 isn't even to RC2 yet, let alone final release,
> surely a lot of people will be using old groffs for quite some time.  So
> it might make sense to patch the page anyway.  The dummy character
> escape sequences (`\&`) will do no harm.

I think I'll keep this as a WONTFIX.

The man-pages don't have stable releases (i.e., what you get at the time your 
distro releases is what you'll get forever), so stable users will have this bug 
unfixed forever until they dist-upgrade, even if I fixed it.

Soon (we hope), groff 1.23.0 will be released, so next OS releases (e.g., 
Bookworm) won't have this bug (and many others that you fixed).

So, the only problem is for those who use stable distros, but somehow install 
the fresh man-pages.  That can be random people that install random packages 
from source, or contributors to the pages.  For both of them, I specify the 
dependencies in the INSTALL file, so I hope they don't blame me too much; they 
should ask their distributor about backporting groff 1.23.0 for installing the 
pages from source, or install groff from source, or be happy with small glitches 
like this :)

However, things like .MR concern me more.  I'd be happy doing some radical 
changes and requiring 1.23.0 as a bare minimum, and use MR right after the 
Bookworm release.  Hopefully that triggers backporting of groff; maybe you can 
do that as a future maintainer of the Debian package?  :P

> Regards,
> Branden
>
> [1] (groff insider stuff)

The parentheses in here help a lot with long messages :)

Cheers,

Alex

>  The preprocessor symbols in the commit above,
>      and the registers they are used to create, might not be necessary; I
>      did notice that the "reset" macro for tables is constructed by the
>      preprocessor by calling a bunch of requests with register arguments
>      that _lack_ the extra layer of escaping that macro definitions often
>      use.  Since the reset macro is defined _before_ the issue of
>      requests that change the troff environment, in principle it's not
>      necessary to use dedicated storage registers, nor a dedicated string
>      for saving the tab stops as was also done after groff 1.22.4.
>
>      However, before trying to optimize this down I have a bigger
>      question--why the hell doesn't GNU tbl set up an _environent_ for
>      table entries (and a separate one for text blocks)?  As I understand
>      it, relieving the tedium of manipulating long sequences of formatter
>      parameters is exactly what environments are _for_.  James Clark was
>      no fool, so I have to speculate that he re-implemented tbl very
>      early, maybe even before GNU troff itself.  That would explain the
>      indirection of all the tbl-internal register names through
>      preprocessor macros, since AT&T troff identifiers were limited to
>      two characters but he surely had longer ones planned.  Another
>      limitation of AT&T troff was that there were only three
>      environments, so he _couldn't_ add new environments--macro packages
>      frequently allocated all three to distinct purposes.  Maybe at some
>      point there was a notion of keeping GNU tbl separately usable with
>      AT&T troff, but if so that notion was abandoned long ago.
>
>      And yet no refactoring of GNU tbl to use environments to (1) make
>      itself, and its output, more comprehensible and (2) reduce the
>      amount of document expansion when preprocessing by tbl ever took
>      place.  Document expansion by preprocessors is not a concern for
>      storage or processing speed reasons in 2022, but it remains valuable
>      for troubleshooting the preprocessors themselves, so that a
>      developer doesn't have to wade through an ocean of irrelevancies to
>      locate the spots where bugs lurk.  Of the 31 bugs that have _ever_
>      been filed against GNU tbl in Savannah, 18 of them have been fixed
>      since the groff 1.22.4 release.  (3 are invalid, 1 was fixed in
>      1.22.4, and the remaining 9 are at large.)
>
>      
> https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=225&advsrch=0&status_id=0&resolution_id=0&submitted_by=0&assigned_to=0&category_id=109&bug_group_id=0&severity=0&summary=&details=&sumORdet=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=5&history_date_monthfd=12&history_date_yearfd=2022&chunksz=50&spamscore=5&boxoptionwanted=1

--
<http://www.alejandro-colomar.es/>

OpenPGP_signature
Description: OpenPGP digital signature