[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: \: re-enables hyphenation--should it?
From: |
G. Branden Robinson |
Subject: |
Re: \: re-enables hyphenation--should it? |
Date: |
Fri, 7 Aug 2020 00:48:56 +1000 |
User-agent: |
NeoMutt/20180716 |
At 2020-07-31T17:41:06-0500, Dave Kemper wrote:
> On 7/31/20, Larry Kollar <larry.kollar@me.com> 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