Re: Within `@code`, `@-` and `@/` are handled the same

[Werner LEMBERG]

> 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