[bug #61734] [man] localize like other packages

[G. Branden Robinson]

Update of bug #61734 (project groff):

                  Status:                   Fixed => Need Info              

    _______________________________________________________

Follow-up Comment #8:

Hi, Dave!

[comment #7 comment #7:]
> I believe you that this is fixed for real in -man, but the -me change does
not seem entirely valid.  The new code added:
> 
> .\" Set package default hyphenation mode, but override it with groff's
> .\" localized value if available.
> .hy 6
> .do hy \\n[\\*[locale]*hyphenation-mode-trap]
> 
> says in the comment that it conditionally uses groff's localization if
available, but in the code unconditionally overwrites the ".hy 6" with
whatever is in the localization register--which, if it doesn't exist, is
interpolated as 0, almost certainly not what is intended.

My reasoning here is that a legacy troff will ignore the `do` request
completely since it won't be a request or the name of a defined macro.

However, I didn't test this change against any other troff implementation, so
it's possible my reasoning is wrong.

Are you testing with Heirloom Doctools troff?  I just now checked their doc.ps
document--their 78-page expanded version of CSTR #54--and don't find myself
much the wiser.  It says if a `cp` request is encountered, a bunch of groff
compatibility features are turned on no matter what.  `.cp 0` simply turns on
more of them.  `.cp 1` on the other hand, apparently, does not get Heirloom
out of groff compatibility mode altogether.

On the gripping hand, groff e.tmac does not issue a `cp` request.

If I understand Heirloom's manual correctly, then to simulate groff's
compatibility mode, you have to issue `do xflag 0`.

> The straightforward solution for groff is to sequester the second .hy call
behind an ".if r" on the register.
> 
> This breaks the package's compatibility with other *roffs, which probably
lack the r conditional (even Heirloom, which has numerous groff extensions,
lacks it), torpedoing one of the stated reasons for the dual .hy setting. 
There may be some clever way I'm not thinking of to preserve that
compatibility, but at least the groff behavior should be correct in the case
where no localization register is set.

I infer that `do` was deliberately engineered by groff to perform such
sequestration, and it appears to me that Heirloom has muddied the waters by
giving it different default semantics.

> "[Extension/xflag level] 1 enables extensions except for direct access to
long names, i.e., *.abcde* will be interpreted as request *ab* with argument
*cde* and \*[xyz] refers to the string named *[* followed by the text *xyz]*. 
Long names can be accessed using the *do* request, e.g., *.do de abcde*, *.do
if 1* \*[xyz].  This level is the default.

(In other news, Savane's "rich text" markup seems to be kind of crap.  I can't
figure out how to set "\*[xyz]" in bold.  If a word starts with '*', the next
'*' turns it off, without any way to escape it or to add a zero-width break
that looks like a word boundary to it.  Maybe it's possible, but the "Rich
Markup" help page offers no clues.)

So, that's kind of frustrating.  I'm deliberately trying to accommodate legacy
troff users and Heirloom is getting the way with this complex feature that
syntactically claims groff compatibility (also see how they set the .g
register) without being willing to support all of groff's features.

> This maybe should be a new bug report, since the current one is primarily
concerned with -man, but I thought I'd float it here first since this is where
the commit was registered.

First let's confirm if I'm understanding the situation correctly!

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61734>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/