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 <g.branden.robin...@gmail.com>
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 <https://savannah.gnu.org/bugs/index.php?58162>.
Thanks to John Gardner and Ingo Schwarze for the discussion.
commit f25eba40278f5a6b8b370193755c2341722bc641
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
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 <g.branden.robin...@gmail.com>
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:
<https://savannah.gnu.org/bugs/?65702>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
