[bug #64243] [troff] expose interface to margin character "stickiness"

[G. Branden Robinson]

URL:
  <https://savannah.gnu.org/bugs/?64243>

                 Summary: [troff] expose interface to margin character
"stickiness"
                   Group: GNU roff
               Submitter: gbranden
               Submitted: Tue 23 May 2023 03:56:15 PM UTC
                Category: Core
                Severity: 1 - Wish
              Item Group: Feature change
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Tue 23 May 2023 03:56:15 PM UTC By: G. Branden Robinson <gbranden>
Our Texinfo manual says (after some recasting presently in my working copy):


     The margin character is a property of the output line; the margin
     character last configured when the line is output controls.  If the
     margin character is disabled before an output line breaks, none is
     output (but see below).
[...]
   For compatibility with AT&T 'troff', a call to 'mc' to set the margin
character can't be undone immediately; at least one line gets a margin
character.

     .ll 10n
     .nf
     .mc |
     .mc *
     .mc
     foo
     bar
         => foo        *
         => bar


It _appears_ that GNU troff uses two separate flag bits to keep track of this
business, "on" and "next" (as usual, James Clark's naming practices are not
transparent to me).

It would be nice to reconceptualize this phenomenon as margin character
"stickiness", such that, if the margin character is "sticky", you can change
it but not remove it for the current output line, and not merely have this be
a quirky property that attaches only to the first output line affected by an
`mc` request enabling a margin character.

I _think_ exposing this might also help programs like gdiffmk with a problem
that has long afflicted them.  I can't find where I saw this right now, but
I've seen what seemed a fairly important standards document (knowing me,
probably for Ada or POSIX) that apologized for its change bar tool having an
off-by-one error.   I _think_ this had to do with an output line ending a
paragraph either getting a change bar when it shouldn't have, or vice versa,
and the problem arising from the fact that a change occurred on a _source
line_ that wasn't the last in the paragraph.

If I'm right, that would make the change worth it.

An interface to margin character stickiness might be in supporting a third
argument to `mc`.  A case against would be that people might want to
manipulate stickiness separately from the character itself or its placement
(and making them retype these things opens avenues for error).

Another avenue would be to add a request, maybe `mcsticky`, which would work
like `linetabs` and `vpt`, and interpret a Boolean value: >0 on, otherwise
off.  I guess I'd be morally compelled to add a read-only Boolean-valued
register `.mcsticky` to reflect the state.

I also wonder if we could get away with dropping AT&T compatibility altogether
for this behavior, since it is so specialized.







    _______________________________________________________

Reply to this item at:

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

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