Follow-up Comment #35, bug #66392 (group groff): [comment #33 comment #33:] > If this bug fix needs a "NEWS" item because someone might have been > depending on this frankly bizarre behavior, so be it.
It's less about someone depending on a bizarre behavior, and more about being
able to assume behavior is consistent unless release notes say otherwise. New
environments have long been created with a hyphenation language defined. Now
they're not (if the change stands). This means nothing typeset in a new
environment will get automatic hyphenation unless the user explicitly ".hla"s
or ".evc"s in every one. That will break some historical usage--not because
someone was relying on this behavior per se, but because they were relying on
the hyphenation language having a default setting.
Really, every setting _should_ have a reasonable default. And it's hard to
argue that "none" is the most reasonable default for a hyphenation language.
But what _is_ most reasonable? This raises the thorny question of how
environments should be initially populated--the very issue you said (comment
#23) you didn't want to adjudicate before 1.24. Unfortunately, I don't think
the issues are as separable as you want them to be. I think letting the .hla
change go into 1.24 without resolving this general environmental problem is
doing users a disservice. You can spackle over the problem by having the
various macro packages set defaults for the environments they use, but this
still doesn't cover users who use custom environments in their own documents
or personal macro sets.
Hence my saying that deferring bug #66387 until post-1.24 is the path of least
resistance. (Other than your resistance to it. :)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66392>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
