[bug #65954] [troff] next-generation alignment and adjustment control

[G. Branden Robinson]

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