[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Zero Width Space

From: Alejandro Colomar
Subject: Re: Zero Width Space
Date: Sun, 5 Jun 2022 17:07:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0

Hi Ingo,

On 6/5/22 14:31, Ingo Schwarze wrote:
- “no-op escape”

But this one, or a variation thereof, might perhaps sever the knot.
It avoids both the very misleading terminology "input break"
and the confusion with the Unicode "ZERO WIDTH SPACE", and it
very accurately describes what this escape sequence does: nothing.
It is usually not inserted for some effect it might have but
merely to prevent an adjacent punctuation character from being
the first character on an input line, the last character before
an input ASCII space or tab character, or the last character on
an input line.  Even when used to disable kerning (which i would
expect to be rare, in particular compared to the other use cases),
thinking along the lines of "let's have a no-op instead of kerning"
or "let's insert a no-op because there will be no kerning between
the adjacent characters and a no-op" would make sense to me.

Let me comment on this one as a non-expert groff user here.
"no-op escape" makes a lot of sense in cases like

    \&. This line contains a leading '.'

Because it does literally nothing, and prevents having . as the first thing. If this were the only place it can be used, I'd say this name is perfect, and better than "non-printing input break" (NPIB).

BUT, it doesn't make any sense to me here:

    .B foo\&

If that were a no-op, I wouldn't write it (why would I write something that does nothing???). What I want here is something that really has an operation: join input lines.

Considering an overall of the situations where this escape is useful, I think NPIB makes more sense to me.

I still think that "zero-width non-breaking space" would work, too,
because it's also accurate, avoids the very wrong words "input break",
and does not cause confusion in relation to Unicode.  But your
suggestion has the advantage of being shorter and easier to understand.

A merge of terms came to my mind just now, which may make sense to you:

How about "non-breaking escape" or "non-printing escape" (not necessarily in that order of preference)?



Alejandro Colomar

reply via email to

[Prev in Thread] Current Thread [Next in Thread]