bugGNU roff - Bugs: bug #63635, [troff] support `hydefault`...

 
 

bug #63635: [troff] support `hydefault` register or similar

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Mon 09 Jan 2023 04:20:38 PM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.24.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 28 Apr 2025 09:44:22 PM UTC, comment #15: 

Ugh, meant `verbatim`, not `verbose`. (Can't Savannah use markdown or something?)

Anonymous
Mon 28 Apr 2025 09:42:35 PM UTC, comment #14: 

Thanks for the explanation, Branden. To provide a TL;DR of your answer to my question, `hydefault` is expected to be used in localization and macro files rather than in manpages themselves.

To summarize the difference between `hydefault` and my proposal for neatroff, with the input
+verbose+
.hy 2
.nh
.hy
-verbose-
the former will set hyphenation mode to whatever was set by the last `hydefault` call (in a macro package or similar), whereas the latter will set hyphenation mode to 2.

My understanding is that the proposals would result in the same effect (localization files can configure which hyphenation mode argumentless `hy` sets), the only significant difference being that with my proposal calling regular `hy` with an argument changes the default mode. It is unclear to me whether this is an advantage or a disadvantage.

Anonymous
Mon 28 Apr 2025 04:37:02 AM UTC, comment #13: 

At 2025-04-27T18:35:51-0400, anonymous wrote:

> comment #11:
> > comment #10:
> >> neatroff's maintainer's opinion is that this change is unnecessary,
> >> because one can save the hyphenation mode to a register before
> >> disabling it.
> >
> > Part of my motivation for the new groff feature is that there is no
> > portable way to do that.
> >
> > If one doesn't care about AT&T troff and can presume the
> > availability of groff's `.hy` register extension, then that
> > approach is fine.
> >
> > Man pages, for example, can't make that presumption.
>
> But isn't that the same problem with `hydefault`, which will also be a
> groff extension?


No, because of the quirky/surprising meaning of the `hy` request when
given no argument (said meaning being traceable deep into 1970s *roff
history[1]).  People, especially man page authors, tend to assume it
means "restore the previous hyphenation mode", just like `ft` and `ps`
without arguments restore the previous font selection and type size,
respectively.

But it doesn't.  (I'd agree with anyone who argued that it should have,
but this opportunity was squandered 50 years ago.)  `hy` without an
argument restores the "default" hyphenation mode, which in AT&T troff is
"1".  groff maintained "compatibility" with this behavior even though it
was no help in producing identical automatic hyphenation breaks (the
hyphenation systems and patterns are strongly dissimilar).  In defense
of groff to date, discarding this aspect of portability for some other
behavior raises the question of what the new behavior should be, an
issue not heretofore addressed.  This is my crack at it.

The new `hydefault` request (1) permits language localization macro
files to configure a default automatic hyphenation mode that congrues
with the expectations of the corresponding language-specific hyphenation
patterns and (2) gives the groff installation the ability to configure
the default hyphenation mode on a per-environment basis.  While this
power could futhermore be exercised by a *roff document,[2] the
envisioned use case is in a site configuration file like "troffrc",
"man.local", or "mdoc.local", so that the machine administrator can
configure hyphenation to their preference.

So in this scenario, it doesn't matter that the extension is not
exercisable portably in a man page.  Indeed, such exercise would largely
defeat the purpose, though I know some man page authors have a stronger
desire to impose their formatting preferences on the reader than they do
to compose a man page that is adaptable to the reader's preferences.

As the "NEWS" file says:


*  A new request, `hydefault`, and read-only register, `.hydefault`,
   manage the default automatic hyphenation mode of an environment.
   This resolves a long-standing problem of *roff formatting.

     When processing input like this,
     .nh
     and we temporarily shut off automatic hyphenation,
     .hy
     the foregoing request would not do exactly what we expect.

   AT&T and other troffs apply a hyphenation mode of 1 to the final
   input line (and subsequent ones), rather than restoring the mode in
   use before the `nh` request.  Apart from overturning user
   expectations, for GNU troff "1" is not an appropriate mode for its
   English hyphenation patterns.  (For example, "alibi" would break as
   "ali-bi" instead of "al-ibi" after this argumentless `hy`
   invocation.)  With updates to groff's localization files accompanying
   this release, the foregoing input now works as desired.


Adjustment suffers from a similar problem; see bug #65954.

> (By the way, neatroff also has register `.hy`.)


Yes.  That's immaterial to the problem I tried to solve with
`hydefault`.

[1] See, for example, PWB/UNIX 1.0 sources, which predate Seventh
    Edition Unix (1979).

    https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s7/croff/n5.c


casehy(){
        register i;

        hyf = 1;
        if(skip())return;
        noscale++;
        i = atoi();
        noscale = 0;
        if(nonumb)return;
        hyf = max(i,0);
}


[2] A (non-man-page) document that otherwise employs automatic
    hyphenation might want create and use an environment to shut it off,
    perhaps to quote a passage in a foreign language that groff doesn't
    support.

G. Branden Robinson <gbranden>
Group administrator
Sun 27 Apr 2025 10:35:44 PM UTC, comment #12: 


comment #11:

>
> comment #10:
> > neatroff's maintainer's opinion is that this change is unnecessary, because one can save the hyphenation mode to a register before disabling it.
>
> Part of my motivation for the new groff feature is that there is no portable way to do that.
>
> If one doesn't care about AT&T troff and can presume the availability of groff's `.hy` register extension, then that approach is fine.
>
> Man pages, for example, can't make that presumption.


But isn't that the same problem with `hydefault`, which will also be a groff extension? (By the way, neatroff also has register `.hy`.)

Anonymous
Sun 27 Apr 2025 02:27:00 AM UTC, comment #11: 


comment #10:

> neatroff's maintainer's opinion is that this change is unnecessary, because one can save the hyphenation mode to a register before disabling it.


Part of my motivation for the new groff feature is that there is no portable way to do that.

If one doesn't care about AT&T troff and can presume the availability of groff's `.hy` register extension, then that approach is fine.

Man pages, for example, can't make that presumption.

G. Branden Robinson <gbranden>
Group administrator
Sun 27 Apr 2025 01:13:24 AM UTC, comment #10: 


comment #9:

> comment #7:
> > A patch I've recently submitted to neatroff might be relevant here.
>
> Neatroff's maintainer can of course make his own call about this, but I would prefer to see patches to other roffs that mimic enhancements to groff use the same syntax as groff's version of the enhancement if at all feasible.  This increases cross compatibility, benefiting users by letting them move more easily from one roff implementation to another.


Sorry for not responding earlier, I wasn't notified of your reply and didn't check.

neatroff's maintainer's opinion is that this change is unnecessary, because one can save the hyphenation mode to a register before disabling it.

Anonymous
Mon 13 Jan 2025 08:40:55 PM UTC, comment #9: 

comment #7:

> A patch I've recently submitted to neatroff might be relevant here.


Neatroff's maintainer can of course make his own call about this, but I would prefer to see patches to other roffs that mimic enhancements to groff use the same syntax as groff's version of the enhancement if at all feasible.  This increases cross compatibility, benefiting users by letting them move more easily from one roff implementation to another.

Dave <barx>
Group Member
Mon 13 Jan 2025 01:46:11 PM UTC, comment #8: 

Noticed the "Fixed" too late.

Anonymous
Mon 13 Jan 2025 01:45:22 PM UTC, comment #7: 

A patch I've recently submitted to neatroff might be relevant here. In essence, my proposal was this:
- add env-local register `.hy1`, default value is 1
- `hy` request with non-zero argument sets `.hy1`
- `hy` without argument sets hyphentation mode to:
  a) 1 if compatibility mode is enabled
  b) to the value of register `.hy1`

This means that outside compatibility mode, one will be able to disable and re-enable hyphenation like this:

.hy 2
Lorem
.nh
ipsum
.hy
dolor...


The `.hy1` register isn't strictly necessary on groff's side, I've added it because neatroff tends to store lots of its settings in registers.

~ onf

Anonymous
Wed 20 Mar 2024 05:46:59 PM UTC, comment #6: 

comment #4:

> comment #0 here mentions that hydefault defaults to 1, but the
> Texinfo manual does not.


Remedied in commit 98f174586.

Dave <barx>
Group Member
Sun 03 Mar 2024 02:58:03 AM UTC, comment #5: 

comment #4:

> comment #3:
> > A) The hyphenation mode itself is already a property of the
> > environment.
>
> True, but this to me doesn't argue either for or against having the default also be per-environment.  (The .hy default before this change was global despite the hyphenation mode being per-environment.)


I think an idiom commonly seen in man pages, but which never* worked does the arguing.


When processing input like this,
.nh
and we temporarily shut off automatic hyphenation,
.hy
the foregoing request does not do exactly what we expect.


(In fact this is the example I put in the NEWS entry.)

  • "Never".  You might get lucky and words wouldn't be wrongly hyphenated afterward, depending on the breaks (literally)--a roll of the dice.


> > C) Having the hyphenation mode default also be per-environment
> > means that you can invoke `hy` without arguments in any given
> > environment and it will "do the right thing".
>
> This seems situational.  Since new environments can be created on the fly, if one creates an environment to, say, handle a footnote region, and calls argumentless ".hy" in that environment, it seems like the "right thing" is to use the hydefault set for the rest of the document, and the less right thing (which this request was specifically designed to avoid) is to set it to 1.


Yes, but that's a weirdness of the default environment having all of the formatter's stock parameters no matter how early and how extensively they're customized for environment 0.  There are many other such weirdnesses, which is why `evc 0` is commonly seen in groff macro packages.
 

> (Side note: comment #0 here mentions that hydefault defaults to 1, but the Texinfo manual does not.)


I'm not sure how prominently it's worth documenting, given that the stock troffrc loads "en.tmac" which sets the hyphenation mode default to 4 (or 6), and other localization macro packages work similarly.

> The multiple-language use case is compelling.  However, since the new knob exists at all as a safety net for those who don't read the documentation closely enough to know that .hy doesn't work like other requests, I wonder if there's a case to be made for making it work best for those doing simple things, and assuming advanced users have done their homework.


That's what my approach attempts to do, without complicating the formatter with respect to its default hyphenation mode...default.

G. Branden Robinson <gbranden>
Group administrator
Sun 03 Mar 2024 02:16:47 AM UTC, comment #4: 

comment #3:

> A) The hyphenation mode itself is already a property of the
> environment.


True, but this to me doesn't argue either for or against having the default also be per-environment.  (The .hy default before this change was global despite the hyphenation mode being per-environment.)

> B) Different environments might be used for setting text in
> different languages.


That's a valid point.

> C) Having the hyphenation mode default also be per-environment
> means that you can invoke `hy` without arguments in any given
> environment and it will "do the right thing".


This seems situational.  Since new environments can be created on the fly, if one creates an environment to, say, handle a footnote region, and calls argumentless ".hy" in that environment, it seems like the "right thing" is to use the hydefault set for the rest of the document, and the less right thing (which this request was specifically designed to avoid) is to set it to 1.

(Side note: comment #0 here mentions that hydefault defaults to 1, but the Texinfo manual does not.)

The multiple-language use case is compelling.  However, since the new knob exists at all as a safety net for those who don't read the documentation closely enough to know that .hy doesn't work like other requests, I wonder if there's a case to be made for making it work best for those doing simple things, and assuming advanced users have done their homework.

Dave <barx>
Group Member
Sun 03 Mar 2024 12:11:33 AM UTC, comment #3: 

comment #2:

> Its intended use would seem to call for making the hydefault value global.  Can you speak to the rationale for making it environment-specific?


Sure.

A) The hyphenation mode itself is already a property of the environment.  That is, you can have different hyphenation modes in different environments.

B) Different environments might be used for setting text in different languages.

C) Having the hyphenation mode default also be per-environment means that you can invoke `hy` without arguments in any given environment and it will "do the right thing".

Does this shed light on the matter?

G. Branden Robinson <gbranden>
Group administrator
Sat 02 Mar 2024 09:47:48 PM UTC, comment #2: 

Its intended use would seem to call for making the hydefault value global.  Can you speak to the rationale for making it environment-specific?

Dave <barx>
Group Member
Sat 02 Mar 2024 06:26:23 AM UTC, comment #1: 


commit 62718e09cd435632b6d05b751205fa24fc88e79f
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Mar 1 23:42:20 2024 -0600

    [troff]: Document new `hydefault` feature.

    * NEWS:
    * doc/groff.texi.in:
    * man/groff.7.man:
    * man/groff_diff.7.man: Do it.

    Fixes <https://savannah.gnu.org/bugs/?63635>.

commit ac229b0e9a6bf99b7c45a497b73bc6e7a06d2d69
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Mar 1 22:36:36 2024 -0600

    [tmac]: Migrate localization pkgs to `hydefault`.

    [tmac]: Migrate localization packages to `hydefault` request.

    * tmac/cs.tmac:
    * tmac/de.tmac:
    * tmac/en.tmac:
    * tmac/es.tmac:
    * tmac/fr.tmac:
    * tmac/it.tmac:
    * tmac/ru.tmac:
    * tmac/sv.tmac: Set the hyphenation mode default appropriately per the
      hyphenation patterns and the value of the trap-awareness bit.

    * tmac/ja.tmac:
    * tmac/zh.tmac: Set the hyphenation mode default to zero.

commit 965de3c1a3d4417b05a15b1d0bdedb75d362123d
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Mar 1 22:23:31 2024 -0600

    [troff]: `.hy` selects default hyphenation mode.

    * src/roff/troff/env.cpp (hyphenate_request): If given no argument, set
      hyphenation mode to the configured default.

commit dc39883e9fb9a3972a7f2d11bac297ad30bb0b6a
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Mar 1 22:13:59 2024 -0600

    [troff]: Add new `hydefault` request.

    * src/roff/troff/env.cpp (set_hyphenation_mode_default): New function
      sets the environment's default hyphenation mode.

      (init_env_requests): Wire up `hydefault` to foregoing function.

    * src/roff/troff/env.h (class environment): Declare foregoing function
      as a friend, permitting mutator access.

commit 04c737951b9b232f06598ca8586c35bc898fe42d
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Mar 1 21:26:54 2024 -0600

    [troff]: Add `.hydefault` read-only register.

    ...storing the environment's default hyphenation mode.

    * src/roff/troff/env.h (class environment): Add private member variable
      `hyphenation_mode_default` and declare public member function
      (accessor) `get_hyphenation_mode_default`.

    * src/roff/troff/env.cpp (environment::get_hyphenation_mode): Implement.

      (environment::environment): Initialize new member variable in ordinary
      and copy constructors.

      (environment::copy): Copy new member variable.

      (environment::print_env): Report environment's hyphenation mode
      default.

      (init_env_requests): Wire up hyphenation mode default value to
      `.hydefault` troff register.

      (class hyphenation_default_mode_reg): Add class.

      (hyphenation_default_mode_reg::get_string): Implement.


G. Branden Robinson <gbranden>
Group administrator
Mon 09 Jan 2023 04:20:38 PM UTC, original submission:  

A comment in tmac/an-ext.tmac says it all.


.\" In AT&T troff, there was no register exposing the hyphenation mode,
.\" and no way to save and restore it.


In man pages, we see people fiddle with `hy` requests, often seemingly under the assumption that it works like `ft`; that calling it without arguments will restore the previous setting.

But it doesn't, and never has.  `.hy` without an argument means `.hy 1`, which is just about useless for all our hyphenation patterns.

I propose to add a (writable) internal register, `hydefault`, to house that value that an argumentless `hy` request will set.

Its default value (in the formatter) would be `1`, retaining 50 years of AT&T troff compatibility.

However, in groff's localization files, this register would be updated to something sensible for the locale.

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-03-02 gbranden Dependencies- bugs #65099 is dependent
    2024-03-02 gbranden DependenciesRemoved dependency to bugs #65099 -
    2024-03-02 gbranden Dependencies- Depends on bugs #65099
    2024-03-02 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.24.0
    2024-03-02 gbranden StatusNone In Progress
        Assigned toNone gbranden
    2023-01-09 gbranden Severity3 - Normal 1 - Wish

    Back to the top

    Powered by Savane 3.15-ef91.
    Corresponding source code