On Sun, Mar 15, 2026, G. Branden Robinson wrote:
> I remain convinced that the hyphenation language should be a
> property of the environment, rather than golbal, because the
> hyphenation "mode" that determines the acceptable locations within
> a word for hyphenation breaking is already environmental _and_
> the hyphenation mode is only intelligible when the hyphenation
> language is known.
I'm not so convinced.
It is reasonable to assume that a document's language remains the
same throughout.
It is equally reasonable to assume that changes to hla occur rarely,
(for example, a passage of text cited in a language different from
the overall).
In such cases, the decision to change hla rests with the document
creator, who introduces the desired alternate hyphenation language
into the current environment with .hla as needed.
Thus, there is no compelling reason *from an end user's or a macro
writer's perspective* to make .hla environmental.
hla (global)
- user wants to switch languages
- user enters .hla [lang]
hla (environmental)
- user wants to switch languages
- user enters .hla [lang]
No change.
> Please find in a footnote an illustration of my claim that the
> hyphenation mode is a property of the environment.[1]
It does make sense for the hyphenation mode to be environmental;
shorter or longer line lengths, rag vs. justified copy, larger or
smaller text, etc can trigger a need to change .hy momentarily, i.e.
within a specific environment.
> Dave and Peter's objections seemed to center around changing the
> formatter's default behavior in this respect without ensuring that
> full-service macro packages were prepared for the change first--a
> reasonable demand. In particular, macro packages need to know what they
> can expect when they create a new environment.
Quite so. The key word in what I wrote, above, is "compelling".
I don't see the need for the proposed change--not be construed as
my having objections. If the change is implemented, I'll make the
trivial alterations to mom to bring her in line.
> (2) Adapt existing packages to the foregoing change. Frequently this
> will mean changing request sequences like this (from our "s.tmac"):
>
> .ev k
> .evc 0
> .ev
>
> ...to this.
>
> .ev k 0
> .ev
Does that mean .evc will be deprecated or removed?
--
Peter Schaffter
https://www.schaffter.ca
