Follow-up Comment #36, bug #66392 (group groff): At 2025-02-06T22:52:09-0500, Dave wrote: > Follow-up Comment #34, bug #66392 (group groff): > > [comment #33 comment #33:] >> Maybe a better model is for the hyphenation code _and_ language >> to be global instead. Dave suggested this, > > This is a misreading of what I said. (Or possibly a miswriting on my > part.)
I wasn't trying to do that, so I apologize if I misstated your position.
> My suggestion was to retain the historical behavior (the mode
> per-environment, and the language global) based on what I expect is
> the commonest usage--which is what default behavior is for.
Does the commonest usage include any of:
1. Explicitly altering the hyphenation language without recourse to a
localization macro file (that is, using the `hla` request)?
2. Composing a document in a language other than English?
If it doesn't, then making the hyphenation language environmental
doesn't alter observed behavior. To see it, one must do one of:
A. Use `.hla`.
B. Specify `-mfr` or similar.
C. Use `.mso fr.tmac` or similar.
I think all of these are minority uses, not the common case. Though I
admit I'd like to see more uptake of groff by non-English language, and
multilingual, documents.
> Any deviation from the default can still be managed manually.
Many bugs can be worked around.
>> bug #66387 astonished me. And it appears to be astonishing
>> others, including Tadziu. That this aspect of formatter
>> behavior kinks even _his_ eyebrow should give us pause.
>
> I agree. It's worth considering and not insane to change it.
> However, onf called for the behavior to change, and Tadziu did not--he
> even wrote "There's nothing really wrong with the way it is now, and
> arguments can even be made for keeping it this way." (It might be
> unclear because "the way it is now" is ambiguous, since it recently
> changed in git. But the challenge specifically cited 1.23 or earlier,
> and the context of his comments make clear he's talking about the 1.23
> behavior.)
It's also ambiguous with respect to the coupling of hyphenation
parameters to the environment tout court versus just the selection of
hyphenation language.
So while it seems we all agree he was astonished by 1.23.0 behavior,
it's not clear what he was...I won't say "endorsing", but refusing to
condemn.
> So it's also not insane to leave it as it historically has been.
To me, deliberately reverting a bug fix comes perilously close to the
line of insanity. When the bug fix causes (or exposes) collateral
defects, that is of course a problem, and that has before occurred in
this release cycle (and I'm still working on repair of one of them).
However, in this case, the diagnosis of collateral defects depends on
(a) an interpretation of our documentation contrary to its explicit
meaning (more on this on the groff@ list) and (b) reliance of the user
on undefined behavior, which in some configurations is explicitly called
out as unsupported ("should be avoided", it says passively). That is
why I quoted our Texinfo manual at such length. What does hyphenation
mode 32 mean when using the English language patterns?
> I don't think list opinion has coalesced around one option or the
> other.
There seems to be a consensus that bug #66387 is startling.
But none yet regarding what should be done about it. I had thought the
answer was obvious so I got surprised a second time.
> But probably not a lot of people are writing multilanguage documents
> where languages are separated by environment, so there may not be much
> more input.
And that, I think, cuts against your "commonest usage" argument.
I think it cuts against even the second commonest usage, after we agree
to disregard the 800 lb. gorilla known as "rendering English-language
man(7) documents to a terminal device", as having too distorting an
effect on design features.
Thanks to mdoc(7), maybe we need to fall back to third?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66392>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
