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/
