On Fri, Dec 16, 2022 at 07:37:06AM +0000, Werner LEMBERG wrote: > > >> Attached are two patches that fix both issues. Note that the bug > >> with no hyphenation in `@t` is at least 20 years old... > > > > And here's a better fix for the `@t` issue. > > Aaand a hopefully final version that takes care of nesting.
It wasn't clear from your email how this worked. In your test file it used @verb which called \nohyphenation. Removing the @verb command allowed hyphenation in @t in your example. So the issue was not with @t, but with @verb and \nohyphenation. The existing implementation of \nohyphenation was incorrect, as you found. Your patch in your first email looked right and I found it difficult to understand the need for the patch in the second email. It took me a while but I understand the problem with nesting is that \nohyphenation restores hyphenation too soon. I see this now with your newer patch which uses the existing value of \hyphenchar. This could have been explained better, as TeX code is often hard to understand. (Whenever I see an \expandafter, I ask, is it really worth making sense of this?) @t nested inside of @code or @code nested inside of @code may not be very useful. I saw that \nohyphenation was used in the definitions of @key, @verb as well as @code as similar, so it is possible that it comes up somewhere important. I want to fix this in a simple way that is easy to understand in the future. One simple way would be to set \hyphenchar to -1 for all of the tt fonts, and leave it as it is. Then we would not have to deal with the fact that all assignments to \hyphenchar are global. We could then remove the \nohyphenation macro. I am working on a change to do this but it still needs more testing. If needed, we could redefine @- to still allow a hyphenation point by inserting an explicit \discretionary.
