Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

I see an argumentation of user model against the system model point of view. That will never do, because they are different. Secondly, you are fighting about the name (identifier) of an escape sequence using arguments valid of an description. That doesn't make sense. Generally the name 'zero wi

Re: Zero Width Space

On Mon, Jun 06, 2022, Douglas McIlroy wrote: > > if we must find a convenient, shorter alternative, "null > > character" seems the best choice, > > You must be joking. That would be a gratuitous clash in > terminology for a large fraction of groff users. Everybody > who's ever written a C program

Re: Zero Width Space

On Mon, 6 Jun 2022, Douglas McIlroy wrote: I propose a radical solution to the problem of defining \&: return to the cstr54 definition, Hear! Hear! I second that. if we must find a convenient, shorter alternative, "null character" seems the best choice, Please no. The concept of null is

Re: Zero Width Space

> I propose a radical solution to the problem of defining \&: return > to the cstr54 definition, Hear! Hear! > if we must find a convenient, shorter alternative, "null > character" seems the best choice, You must be joking. That would be a gratuitous clash in terminology for a large fraction of

Re: Zero Width Space

Hi Ingo, On 6/5/22 19:09, Ingo Schwarze wrote: .B foo\& bar If that were a no-op, I wouldn't write it (why would I write something that does nothing???). In fact, it does *not* do anything in this particular situation either. [...] Or are you thinking about .TH TEST 1 .

Re: Zero Width Space

I see a mountain." I've carried the original cstr54 definition of \& in my head since my first exposure to *roff: a non-printing, zero width character (NPZWC). I had never seen it defined as a "zero-width space" until I had a look at my version of the info manual (1.22.4),

Re: Zero Width Space

> > What about "input escape" Copy+pasta from my earlier post to a concurrent discussion in another thread: s/input escape/control suppressor/gi s/input escape/command suppressor/gi (This discussion appears to have been split betw

Re: Zero Width Space

Hi, DJ Chase wrote on Sun, Jun 05, 2022 at 09:57:45PM +: > On Sun Jun 5, 2022 at 1:09 PM EDT, Ingo Schwarze wrote: >> Richard Morse wrote: >>> How about "non-breaking escape" >> That's much too broad since most escape sequences are non-breaking. >>> or "non-printing escape" (not necessarily

Re: zero-width space

Hi Branden, Deri wrote on Mon, Jun 06, 2022 at 12:23:19AM +0100: > On Sunday, 5 June 2022 02:58:14 BST G. Branden Robinson wrote: >> A big problem with "zero-width space" is that it falsifies the statement >> that adding a newline or multiple (regular) space characters

Re: Zero Width Space

On 6/5/22, Ingo Schwarze wrote: > That's also too broad for my taste; here are a few more escape > sequences that are non-printing and non-breaking unless i'm > missing something: \{ \} \F \f \H \k \M \m \R \S \s \z > The difference between \& and the others is that \& is a no-op > whereas the oth

Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

t; is only to disagree on "equivalent". yacc is an example, isn't it? yacc is LALR(1): one look-ahead token parsing left to right. No one token is privileged over the others, whether two legs or four. > \& in no way tells the output to device to find a "zero-wi

Re: zero-width space (was Re: How to print a literal '.' as the first character in a line?)

On Sunday, 5 June 2022 02:58:14 BST G. Branden Robinson wrote: > A big problem with "zero-width space" is that it falsifies the statement > that adding a newline or multiple (regular) space characters after a > candidate end-of-sentence character results in inter-sentence sp

Re: Zero Width Space

On Sun Jun 5, 2022 at 1:09 PM EDT, Ingo Schwarze wrote: > > How about "non-breaking escape" > > That's much too broad since most escape sequences are non-breaking. > > > or "non-printing escape" (not necessarily in that order of preference)? > > That's also too broad for my taste; here are a few mo

Re: building without tex (was: zero-width space)

On Sunday, 5 June 2022 09:40:43 BST Ingo Schwarze wrote: > Of course, that implies that subsequently, "make dist" will inevitably > fail, so it won't help much for a serious developer who wants to do > complete testing of whatever changes they are considering. The reason to avoid having a dependen

Re: building without tex (was: zero-width space)

Hi, Ingo! At 2022-06-05T10:40:43+0200, Ingo Schwarze wrote: > G. Branden Robinson wrote on Sat, Jun 04, 2022 at 08:58:14PM -0500: > > > While I have you, Deri raised a point in Savannah #62251 that I'd like > As you correctly say below, #62551. Argh, yes. Once bug numbers get past four digits m

Re: Zero Width Space

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

Re: Zero Width Space

On 6/5/22 17:07, Alejandro Colomar wrote: How about "non-breaking escape" or "non-printing escape" (not necessarily in that order of preference)? Or (I was going to suggest this one, but didn't because it is too long, but neither of those fully convinces me as much as this one): "non-printin

Re: Zero Width Space

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

Re: Zero Width Space

Hi Ingo, > > - “no-op escape” > > But this one, or a variation thereof, might perhaps sever the knot. This is the only one which seems useful, and continues a theme I went for in another email. > It avoids both the very misleading terminology "input break" Yes, very misleading. > It is usually

Re: Zero Width Space

to separate anything. Quite to the contrary, it is usually prepended or appended to something. > - “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 Unico

Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

> On Jun 5, 2022, at 1:37 AM, Dave Kemper wrote: > > No one, including its inventor, seems fully happy with it, but there > also hasn't been an alternate proposal that everyone is happy with. > "Zero-width space" is a nonstarter for its Unicode clash.

Re: Zero-Width Space.

Hi Dave, > No one, including its inventor, seems fully happy with it, but there > also hasn't been an alternate proposal that everyone is happy with. I'd argue if it isn't the proper fix then don't fix it because now there's just something new to fix with more confusion in the short and long term

building without tex (was: zero-width space)

Hi Branden, G. Branden Robinson wrote on Sat, Jun 04, 2022 at 08:58:14PM -0500: > While I have you, Deri raised a point in Savannah #62251 that I'd like As you correctly say below, #62551. > your feedback on. He feels the weight of a TeX installation; other > people probably will too. It invo

Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

term for \& was "non-printing, zero-width character"; the 1992 revision of CSTR#54 expanded that to "non-printing, zero-width filler character" (which seems more misleading than the original, since it does no filling and has nothing to do with the typographical concept of fil

Re: zero-width space (was Re: How to print a literal '.' as the first character in a line?)

wo years ago, but when issues aren't noticed soon, finding > them later is still better than never. They were noticed, and discussed, at the time[1]. "Non-printing input break" isn't my favorite term either, but I think it's _less_ misleading than "zero-width spac

Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

On Saturday, 4 June 2022 22:44:10 BST Dave Kemper wrote: > On 6/4/22, James K. Lowden wrote: > > A "zero width space" is perfectly clear terminology. > > Not to anyone familiar with Unicode's U+200B ZERO WIDTH SPACE, which > doesn't correspond to groff

Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

Hi, James K. Lowden wrote on Sat, Jun 04, 2022 at 03:23:36PM -0400: > On Thu, 5 May 2022 03:40:27 -0500 Dave Kemper wrote: >> To cite the example that originally launched this thread, the old >> docs termed the \& a "zero width space," which Branden has changed

Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

On 6/4/22, James K. Lowden wrote: > A "zero width space" is perfectly clear terminology. Not to anyone familiar with Unicode's U+200B ZERO WIDTH SPACE, which doesn't correspond to groff's \& but to its \: (which groff currently calls the "non-printing brea

Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

eral 'TOKEN_DUMMY') which becomes a "dummy node". > *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". If we ap

Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)

On Thu, 5 May 2022 03:40:27 -0500 Dave Kemper 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 a