[bug #53837] Feature request: mechanism to control .hw/.hy interaction

[Dave]

URL:
  <http://savannah.gnu.org/bugs/?53837>

                 Summary: Feature request: mechanism to control .hw/.hy
interaction
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Fri 04 May 2018 02:44:27 PM CDT
                Category: Core
                Severity: 3 - Normal
              Item Group: Wishlist
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

In bug #53196 comment #1, Werner illustrates a case where it makes sense for
hyphenation points that the user defines with .hw to override the global
hyphenation value set with .hy.

I believe there are equally valid cases where the opposite should hold.  (See
rationale below.)

Thus I am requesting a groff enhancement whereby the user can control whether
a document's .hy setting affects hyphenation points defined with .hw.  This
could be implemented via a new request, new values for .hy (which so far uses
only 6 of its available 32 bits), or some other means.

Or for more flexibility than a new global flag, the .hw request could accept
two different hyphenation markers in its words (- and +, say) to differentiate
hyphenation points that should be subject to .hy from those that should not.

Rationale:

Typically, one varies the hyphenation freedom (via the .hy request) based on
the column width.  In a document that alternates between wide and narrow
columns multiple times, one might adjust the value of .hy at each of these
alternation points.

As it stands, to get the full benefit of these changes, at each of these
points the user must also redefine words defined with .hw.  This becomes
cumbersome in documents with many such words.

While the .hw variations can be wrapped in macros, this is still more effort
than just having a mechanism to control how .hw words are interpreted by .hy,
and also requires that the user maintain (at least) two versions of the .hw
list.  Requiring redundancy in source code is how inconsistencies crop up. 
This is the sort of task perfectly suited for an algorithm, and should not
need manual intervention.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53837>

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