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

Following this thread, I've been reminded of this classic. An old man speaks to his grandson: "When I was young, I looked across the lake and saw a mountain. As I grew up, I looked across the lake and saw so much more than a mountain. Now I am old; when I look across the lake, I see a mou

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 after a >> candidate end-of

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?)

On Sat, 4 Jun 2022 15:53:25 -0500 "G. Branden Robinson" wrote: > Hi James, Hi Brandon, We seem to come at this question from different persepectives. I'm going to try to bring you over to mine. > This is like saying that all states in a finite state machine (FSM) > are equivalent. It's j

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 spacing > being added. (U

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: Zero Width Space

Hi Alejandro, Alejandro Colomar wrote on Sun, Jun 05, 2022 at 05:07:41PM +0200: > On 6/5/22 14:31, Ingo Schwarze wrote: >> Richard Morse write: >>> - “no-op escape” >> But this one, or a variation thereof, might perhaps sever the knot. >> It avoids both the very misleading terminology "input bre

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 describes what this esc

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

Hi, Richard Morse wrote on Sun, Jun 05, 2022 at 07:46:16AM -0400: > Do any of these spark an idea? > > - “processor instruction” > - “parser instruction” > - “special input sequence” Those are too generic. Practically all escape sequences, and practically all roff requests in addition to them,

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. Do any of these spark an idea? - “processor

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

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

Some history: The discussion that prompted the August 2020 terminology change is consolidated in http://savannah.gnu.org/bugs/?58933 (it started earlier on the email list, but that bug report contains links to the relevant email discussion). One point made therein is that the original CSTR#54 ter

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

Hi Ingo, At 2022-06-05T00:19:30+0200, Ingo Schwarze wrote: [...] > the groff documentation uses the term "break" very > consistently, defining it as starting a new output line even though > the current output line is not yet full. Yes, and I have striven to reinforce that consistency wherever pos

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's \& but to its \: (which groff currently >

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 to >> the "non-printing input break

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 break point"). And regardless of who can cla

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

Hi James, [I'm reordering one sentence in your reply.] At 2022-06-04T15:23:36-0400, James K. Lowden wrote: > To insert \& at the start of a line does not affect how the input is > parsed. Yes, it does. $ gdb ./build/troff GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git Copyright (C) 2021 Free So

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 as > easily, but it's more precise and