> It took me a while but I understand the problem with nesting is that
> \nohyphenation restores hyphenation too soon.
Not really: It is rather that `\font` within the group has a different
value than outside the group. For this reason, the group's `\font`
value must be set via `\aftergroup`, not just `\font`.
> 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?)
I would have improved the comments and the commit message after this
your reply :-)
And yes, the solution with `\expandafter` I finally presented was
really necessary to restore `\hyphenchar` correctly after the group.
> @t nested inside of @code or @code nested inside of @code may not
> be very useful.
Well, for LilyPond's documentation, which uses Latin Modern's
`LMMonoLt10` family instead of `cmtt`, also providing macros `@tb` and
`@tbsl` to get typewriter bold and bold slanted, respectively, it *is*
useful: I mainly consider `@code` as an environment where `@set
txicodequoteundirected` and `@set txicodequotebacktick` take effect.
> 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.
Given that nobody complained in the last 20 years, I guess this is a
valid choice. However, I ask you to document this, since it is not
obvious why `@t` disables hyphenation. BTW, will the other output
formats of Texinfo do the same?
> If needed, we could redefine @- to still allow a hyphenation point
> by inserting an explicit \discretionary.
I've seen that you did this, thanks.
Werner
