At 2020-07-31T17:41:06-0500, Dave Kemper wrote: > On 7/31/20, Larry Kollar <[email protected]> wrote: > > It’s a space, which I would presume ends a word. A zero-width space, > > by definition, but still a space. > > I suppose that depends where you're getting your definition. The > groff(7) man page and the Texinfo manual define \: as a "zero-width > break point," which does not suggest the observed behavior in the way > your alternate definition does. > > groff(7) calls \& a "non-printable, zero-width glyph" but the Texinfo > manual calls it a "zero-width space." However, \& does not have the > hyphenation-resetting property that \: does.
In the source code, it definitely creates a space node:
case TOKEN_ZERO_WIDTH_BREAK:
n = new space_node(H0, curenv->get_fill_color());
n->freeze_space();
n->is_escape_colon();
break;
However, this is less help than it might be, because this type is a
parent class from which nothing else seems to create objects. The other
space types create objects of child classes.
case TOKEN_SPACE:
n = new hmotion_node(curenv->get_space_width(),
curenv->get_fill_color());
break;
[...]
case TOKEN_STRETCHABLE_SPACE:
n = new unbreakable_space_node(curenv->get_space_width(),
curenv->get_fill_color());
break;
case TOKEN_UNSTRETCHABLE_SPACE:
n = new space_char_hmotion_node(curenv->get_space_width(),
curenv->get_fill_color());
break;
So I'm still not sure what to think. The class hierarchy makes this
harder to alter than I had hoped, and retain any confidence of not
regressing something.
Regards,
Branden
signature.asc
Description: PGP signature
