On Tue, Feb 4, 2025 at 1:54 PM onf <o...@disroot.org> wrote: > In other words, hyphenation language setting is not local to the > environment... which seems like a really unintuitive behavior,
Being one of the disqualifieds from this challenge (having been in prior discussion about it on savannah), I've had a few extra days to ruminate, and I think I can make a case for the nonintuitive behavior. Historically, environments were intended to be used to store state of page elements (e.g. titles and footnotes) that were separate from running text. One might well want different word-breaking _rules_ in these other elements, but less likely based on a different language. Thus the hyphenation mode (the rules about if and when words can be broken) is part of the environment, but the language to which those rules are applied is global. Notably, this design doesn't _prevent_ anyone changing hyphenation language when they switch environments -- it just doesn't do it automatically. That is, it covers the common case, but gives the user flexibility to handle other cases. With the scope of both hyphenation mode and hyphenation language being documented (the latter less explicitly, but consistent with how other global parameters are documented), the user knows what to expect. Except the number of expert users who've been caught off guard by this weakens that last claim. Also, with the number of available environments expanding from its historical three to its current infinity, arguably the historical purpose of environments is less relevant today. A modern multilingual groff document might well switch environments when switching languages. But is that a common enough case to justify making it the default behavior? Or is that an edge case still best handled manually?
