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

[Gavin Smith]

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.