[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 <g.branden.robinson@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.robinson@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.robinson@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/