[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\&
bar
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)?
Cheers,
Alex
--
Alejandro Colomar
<http://www.alejandro-colomar.es/>
- Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?), (continued)
- Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?), G. Branden Robinson, 2022/06/04
- Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?), Dave Kemper, 2022/06/04
- Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?), Deri, 2022/06/04
- Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?), Dave Kemper, 2022/06/05
- Re: Zero-Width Space., Ralph Corderoy, 2022/06/05
- Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?), Richard Morse, 2022/06/05
- Re: Zero Width Space, Ingo Schwarze, 2022/06/05
- Re: Zero Width Space, Ralph Corderoy, 2022/06/05
- Re: Zero Width Space,
Alejandro Colomar <=
- Re: Zero Width Space, Alejandro Colomar, 2022/06/05
- Re: Zero Width Space, Ingo Schwarze, 2022/06/05
- Re: Zero Width Space, DJ Chase, 2022/06/05
- Re: Zero Width Space, Ingo Schwarze, 2022/06/06
- Re: Zero Width Space, John Gardner, 2022/06/06
- groff man(7) `B` macro behavior with `\c`, and input traps, G. Branden Robinson, 2022/06/05
- Re: groff man(7) `B` macro behavior with `\c`, and input traps, Ingo Schwarze, 2022/06/06
- Re: groff man(7) `B` macro behavior with `\c`, and input traps, John Gardner, 2022/06/06
- Re: groff man(7) `B` macro behavior with `\c`, and input traps, G. Branden Robinson, 2022/06/10
- Re: groff man(7) `B` macro behavior with `\c`, and input traps, Ralph Corderoy, 2022/06/10