URL: <https://savannah.gnu.org/bugs/?65954>
Summary: [troff] next-generation alignment and adjustment
control
Group: GNU roff
Submitter: gbranden
Submitted: Fri 05 Jul 2024 08:08:43 AM 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: Fri 05 Jul 2024 08:08:43 AM UTC By: G. Branden Robinson <gbranden>
Free the users from the surly bonds of `.ad` (with an argument)!
Here's a summary of what I'm pitching, in the style of groff(7).
.ad Enable output line adjustment. Updates \n[.j].
.ad b Enable output line adjustment. Updates \n[.j].
.ad n Enable output line adjustment. Updates \n[.j].
.ad C Align output line to left, right, or center as C is "l",
"r", or "c", respectively. Updates \n[.j].
.ad N Configure output line alignment and adjustment per the
integer N, which must be a valid value of the .j
register.
.na Disable output line adjustment. Updates \n[.j].
\n[.j] Output line alignment and adjustment encoded as an
integer; see .ad and .na. Do not interpret or
perform arithmetic on its value.
(The numerical value of the `.j` register will change under my proposal,
but its semantics are otherwise unaltered: it would continue to work as
it always has. The warning about not interpreting or performing
arithmetic on its value has been present since groff 1.23, and was, I
understand, folk knowledge among *roff practitioners long before that.)
I'm further considering adding two more registers.
\n[.adjust] Output line adjustment enablement (Boolean-valued).
See .ad and .na.
\n[.align] Output line alignment (string-valued; interpolates
"l", "r", or "c". See .ad.
And I'd be happy to implement two new requests to get people out of the
`ad`/`na`/`\n(.j` quagmire altogether.
.adjust Enable output line adjustment. Its is enabled by
default. Updates \n[.j].
.adjust B Enable or disable output line adjustment per Boolean
expression B. Updates \n[.j].
.align C Align output line to left, right, or center as C is "l",
"r", or "c", respectively. Updates \n[.j].
Each of these three tiers builds on the previous. Just the first is
enough to suit my reformist passion, but I think the other two increase
user-friendliness in this area.
The discussion thread started from a
[https://lists.gnu.org/archive/html/groff/2024-06/msg00052.html claim by
Bjarni that I believe to be incorrect (and his underlying model of the
formatter's behavior ill-conceived)].
The [https://lists.gnu.org/archive/html/groff/2024-06/msg00057.html foregoing
summary is from my second reply to him].
[https://lists.gnu.org/archive/html/groff/2024-06/msg00057.html Earlier in the
discussion I mused]:
Decisions still to be made:
1. Whether to expose `.align` and `.adjust(ment)` registers to more
clearly communicate the information encoded in `.j`. The former
would be string-valued, interpolating "l", "c", or "r", and the
latter a Boolean.
2. Whether to introduce new `align` and `adjust` requests to manipulate
these two properties separately. They still would not be usable in
portable man pages.
3. Whether to alter the behavior of the `ad` request, as the attached
patch contemplates. Doing so accommodates man page authors' DWIM
intentions, at some risk to altering the formatting of documents
that follow `.ad c` or `.ad r` with `.ad`, expecting to restore left
alignment instead of merely disabling adjustment. It's not clear to
me how many such documents actually exist. I don't think I've ever
seen one that I didn't write as a test case.
4. Whether to retain AT&T-compatible `ad` behavior in AT&T
compatibility mode. Deciding #3 likely decides this one.
My opinion now is that the answer to all four is "yes".
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65954>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
