On Thu, 5 May 2022 03:40:27 -0500 Dave Kemper <saint.s...@gmail.com> wrote:
> To cite the example that originally launched this thread, the old > docs termed the \& a "zero width space," which Branden has changed to > the "non-printing input break." It may not roll off the tongue as > easily, but it's more precise and descriptive about what the escape > does: it affects how input is parsed, not how output is rendered. > It's not kin to other space escapes like \~ or \|, as the original > term implied. I disagree. That's not what it does. The zero width space does not "affect how input is parsed". It's parsed like all other input -- indeed, exactly like \| and \~. Its only distinction from them is on output. To insert \& at the start of a line does not affect how the input is parsed. *Any* character before a leading dot prevents the dot from being interpreted as a request. The salient difference is that \& introduces nothing into the output stream. Hence, "zero width". To me, the term "non-printing input break" verges on nonsense because it suggests there might be such a thing as "printing input". There is not: input is processed and rendered as output. Input is no more printed than it is written to the keyboard. I humbly suggest on this point we return to status quo ante. A "zero width space" is perfectly clear terminology. The fact that \& is used occasionally to prevent non-requests from being interpreted as requests is incidental, easily explained and understood. Does anyone remember being confused by it? I don't. --jkl
