[bug #65702] tmac/doc.tmac: compatibility mode not restored at end

[G. Branden Robinson]

Update of bug #65702 (group groff):

 Assigned to:gbranden => None   


___

Reply to this item at:

  

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

[bug #65702] tmac/doc.tmac: compatibility mode not restored at end

[Dave]

Update of bug #65702 (group groff):

  Status:   Need Info => None   


___

Reply to this item at:

  

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

[bug #65702] tmac/doc.tmac: compatibility mode not restored at end

[G. Branden Robinson]

Update of bug #65702 (group groff):

Severity:  3 - Normal => 2 - Minor  
  Item Group: Incorrect behaviour => Lint   

___

Follow-up Comment #3:

Ah, it's a theoretical concern.

1.  _groff_ is not _in general_ installed with compatibility mode on by
default, not on any system.

2.  What _does_ happen is that, _if_ "compatibility wrappers" are generated
for certain macro packages, those wrappers get a "cp 1" request injected into
them.

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/tmac.am?h=1.23.0#n301

See in particular line 311.  The logic is fairly old.

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/Makefile.sub?h=1.22.3.real#n137

These wrappers came in via a contribution from Peter Bray in 2015.

https://git.savannah.gnu.org/cgit/groff.git/tree/ChangeLog.122?h=1.23.0#n2103

...to address bug #44784.

3.  The list of macro packages for which compatibility wrappers may be
generated is dynamically generated (by looking in the system troff's "tmac" or
"macros" directory for files _without_ an FSF copyright notice).  In practice,
this tends to include "an", "m", and "s".

4.  "doc" (mdoc) is not in that list.

5.  Solaris 10 evidently never bothered picking up the package from
4.3BSD-Reno or later.  Makes sense, as by the time of that BSD release, AT&T
had an investment stake in Sun and was steering it to a System V base.

So this doesn't really matter much.  Demoting to "minor", "lint".

If it ever causes a problem on an actual system, it can be re-promoted.


___

Reply to this item at:

  

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

[bug #65702] tmac/doc.tmac: compatibility mode not restored at end

[G. Branden Robinson]

Update of bug #65702 (group groff):

 Assigned to:None => gbranden   
 Summary: tmac/doc.tmac: previous state of compatibility
(register '.cp') is not restored at end => tmac/doc.tmac: compatibility mode
not restored at end

___

Follow-up Comment #2:

Revising summary; Bjarni identified the wrong register.

And the value of the registers `.C` and `.cp` aren't what is squarely on
point.

The question is, is the enablement status of AT&T compatibility mode different
when _groff_ finishes reading a macro file than when it started?

_That_ is what can cause input to be processed unpredictably.  The registers
are merely indicia.

Here's background from 4 years ago.


commit 6a37bb5f00d881e50856dc5906f03e64dcacd1ec
Author: G. Branden Robinson 
Date:   Fri Apr 17 00:05:15 2020 +1000

Implement new read-only .cp register.

The register \n[.cp] is specialized and may require a statement of
rationale.  When writing macro packages or documents that use groff
features and which may be mixed with other packages or documents that do
not—common scenarios include serial processing of man pages or use of
the .so or .mso requests—you may desire correct operation regardless of
compatibility mode in the surrounding context.  It may occur to you to
save the existing value of \n(.C into a register, say, _C, at the
beginning of your file, turn compatibility mode off with “.cp 0”,
then
restore it from that register at the end with “.cp \n(_C”.  At the
same
time, a modular design of a document or macro package may lead you to
multiple layers of inclusion.  You cannot use the same register name
everywhere or you risk “clobbering” the value from a preceding or
enclosing context.  The two‐character register namespace of AT&T troff
is confining and mnemonically challenging; you may wish to use groff's
more capacious namespace.  However, attempting “.nr _my_saved_C
\n(.C”
will not work in compatibility mode; the register name is too long.
“This is exactly what .do is for,” you think, “.do nr _my_saved_C
\n(.C”.  The foregoing will always save zero to your register, because
.do turns compatibility mode off while it interprets its argument list.
What you need is:
.do nr _my_saved_C \n[.cp]
.cp 0
at the beginning of your file, followed by
.cp _my_saved_C
at the end.  As in the C language, we all have to share one big
namespace, so choose a register name that is unlikely to collide with
other uses.

* src/roff/troff/input.cpp (do_request, init_input_requests): Implement
  it.

* doc/groff.texi:
* man/groff.7.man:
* man/groff_diff.7.man: Document it.

* src/roff/groff/groff.am:
* src/roff/groff/tests/dot-cp_register_works.sh: Test it.

Enables a fix for .

Thanks to John Gardner and Ingo Schwarze for the discussion.

commit f25eba40278f5a6b8b370193755c2341722bc641
Author: G. Branden Robinson 
Date:   Fri Apr 17 20:41:22 2020 +1000

NEWS: Add item for \n[.cp].

Also use more correct nomenclature for other *roffs.

ChangeLog: Add summary of what \n[.cp] actually _is_.

commit 1474eebe1f83c439dd6d422a311c1c39417fac40
Author: G. Branden Robinson 
Date:   Sun Apr 19 15:24:24 2020 +1000

**/*.{man,tmac}: Save compatibility mode robustly.

Use new \n[.cp] register to save compatibilty mode.

Use register names based on the filename (at the source maintenance
level) to avoid clobbering other files' saved compatibility modes.

tmac/html.tmac: Eliminate reference to saved-compatibility register by
moving its test inside the block where compatibility mode is off.  This
is the only part of this changeset that was not automated.


I might have overlooked _mdoc_, since it had different fingerprints all over
it.

Or it may not have been a problem.

Or someone would have complained about this, except no user of _groff_ on
Solaris 10 has formatted _mdoc_ pages since 2001 or earlier.

I think I'll see if I can reproduce an actual problem here.  If I can't, this
ticket is either lint or invalid.

I should probably hasten to add that not every macro file _needs_ to be
bracketed with compatibility mode saving and restoration logic.  The reasons
are documented and/or obvious, but I leave them as an exercise for the bug
submitter.


___

Reply to this item at:

  

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