Follow-up Comment #33, bug #66392 (group groff): At 2025-02-06T11:20:16-0500, Peter Schaffter wrote: > Follow-up Comment #32, bug #66392 (group groff): > > [comment #31 comment #31:] >> [comment #30 comment #30:] >>> _Is_ there an issue with it? I mean with my diagnosis >>> of the problem and the shape of my solution. >> >> Peter raised one in comment #18 and hasn't yet been able to respond >> to your comment #21 rebuttal (probably due to the system upgrade he >> mentions in comment #11). > > I haven't responded because, complete and illuminating as Branden's > diagnosis is, it answers the "why" of "Why is \n[.hla] not global > regardless of ev?" without addressing the larger issue of whether it's > a good idea for hla to be ev dependent at all.
I think I _did_ address that. My claim is that it makes _no sense_ for the hyphenation language to be global while the hyphenation mode is environmental. Or vice versa. I'm guessing that James Clark's intent, when introducing multilingual hyphenation support in groff 1.07... NEWS: Multilingual hyphenation is supported by new `hpf' and `hla' requests, and by a `\n[.hla]' number register. The -H option has been removed. Files of hyphenation patterns can have comments. ...was not for them to be decoupled, and I made the change that I did based on inference. Now, I'm not certain that I read Clark's mind correctly. I could be wrong. Maybe a better model is for the hyphenation code _and_ language to be global instead. Dave suggested this, and while I don't lean that way, I can see it, and can imagine being persuaded to his side of that argument. I agree that it should be discussed more widely... > The matter needs to be discussed, along with other ev initialization > issues raised in this thread. ...thus: https://lists.gnu.org/archive/html/groff/2025-02/msg00000.html ...which unfortunately has, uh, petered out. Maybe you could reawaken the thread. :) What I _cannot_ imagine is a case for the status quo, or its aforementioned inverse, that isn't grounded solely on inertia. Our documentation has long warned people that the _validity_ of hyphenation modes is _dependent upon the pattern files used_ (and therefore the hyphenation language, which determines the pattern files used). Our Texinfo manual says, in words I've "smithed" somewhat but the claims of which I don't think I've altered: The number of characters at the beginning of a word after which the first hyphenation point should be inserted is determined by the patterns themselves; it can't be reduced further without introducing additional, invalid hyphenation points (unfortunately, this information is not part of a pattern file--you have to know it in advance). The same is true for the number of characters at the end of a word before the last hyphenation point should be inserted. For example, you can supply the following input to 'echo $(nroff)'. .ll 1 .hy 48 splitting You will get s- plit- t- in- g instead of the correct 'split- ting'. English patterns as distributed with GNU 'troff' need two characters at the beginning and three characters at the end; this means that value 4 of 'hy' is mandatory. Value 8 is possible as an additional restriction, but values 16 and 32 should be avoided, as should mode 1. Modes 4 and 6 are typical. A table of left and right minimum character counts for hyphenation as needed by the patterns distributed with GNU 'troff' follows; see the 'groff_tmac(5)' man page for more information on GNU 'troff''s language macro files. language pattern name left min right min ----------------------------------------------------------- Czech cs 2 2 English en 2 3 French fr 2 3 German traditional det 2 2 German reformed den 2 2 Italian it 2 2 Russian ru 2 2 Spanish es 2 2 Swedish sv 1 2 Hyphenation exceptions within pattern files (i.e., the words within a TeX '\hyphenation' group) obey the hyphenation restrictions given by 'hy'. > That's why I agree with Dave: defer the hla change until after 1.24 > and hash things out then. I'm resistant because I see this as a bug fix and I have a visceral dislike of _undoing_ a bug fix. (Postponing one is another matter.) If this bug fix needs a "NEWS" item because someone might have been depending on this frankly bizarre behavior, so be it. I'll write one. (Is "for my document to format correctly, I've been depending on use of a hyphenation mode with no defined semantics vis à vis the pattern files I've been using" a likely scenario?) If we need to furthermore change the full-service macro packages to explicitly copy environment 0 when creating new ones for the package's use for this bug fix to be tolerable, and announce that as an item in "NEWS", so be it. I'll make that change (including submitting a patch to mom to your for approval if she even needs changing) and write one. If the consensus is that coupling hyphenation to the environment was a bad call and shouldn't have been done (though I wonder about setting long passages in one language while having headers and footers of the overarching work in another), then I can make that change, and if it merits a "NEWS" item (probably), so be it. I'll write one. Probably after researching what AT&T troff did, though. It's something that might need to stay in the environment in compatibility mode. I'm not trying to put any load, nor impose any time table, on anyone else. I am willing to put my own effort behind my suggestions, in pursuit of the Principle of Least Astonishment. It's fair to say that 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. If anyone has any suggestions for how I can require less of any other people in this situation (and still fix the bug), please tell me. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66392> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
