Subject: Re: [netmod] artwork folding: dual support modes?

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 09:40:06 +0100 (CET)

"Rob Wilton (rwilton)" <[email-masked]> wrote:
> Hi Adrian,
> 
> I mostly agree with your last sentence.
> 
> I think that if you always preserve whitespace then a single slash is
> fine.  I.e. the single slash just breaks the line, and I think that
> this matches how editors, programming languages, etc normally behave.
> 
> What I’m not keen on is using a single slash, and then automatically
> stripping leading whitespace on the line following a slash.

And this is the solution that I prefer.  The reason for this is that I
view examples as something that is there to illustrate some point to
the reader, and I think that a prettier formatted example with less
noise helps the reader.  I also think that is most cases, this works
well; i.e., most cases are _not_ on the form:

   12345      78990
          ^-------------- I need a line break here

For this problem, I prefer a solution that is intuitive and has less
noise and works for 90% of the cases, than a less intuitive solution
with more noise that works for 100% of the cases.

/martin

> 
> If we want to have control of layout and be able to strip extra
> whitespace then my argument is that it is better to be explicit, and
> using two slashes is one way of achieving this.
> 
> Thanks,
> Rob
> 
> 
> 
> From: netmod <[email-masked]> On Behalf Of Adrian Farrel
> Sent: 27 February 2019 09:41
> To: 'Joel Jaeggli' <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] artwork folding: dual support modes?
> 
> Complete agreement, Joel.
> 
> What follows may look better in proportional fonts.
> 
> With a single slash we can wrap as follows
> 
> 1234567        9012345
> 
> Goes to…
> 
> 1234567    \
>     9012345
> 
> …and unwrapping is easy.
> 
> However, if I want to manually wrap the line with indentation
> 
> The quick brown fox jumps over the lazy dog
> 
> ..going to…
> 
> The quick brown fox\
>       jumps over the lazy dog
> 
> …I am going to unfold as…
> 
> The quick brown fox      jumps over the lazy dog
> 
> 
> Conversely, if I resolve this second case by stripping leading spaces
> I get…
> 
> The quick brown foxjumps over the lazy dog
> 
> So I have to fold as…
> 
> The quick brown fox \
>       jumps over the lazy dog
> 
> But this causes the first case to unfold as
> 
> 1234567    9012345
> 
> …i.e., with missing spaces.
> 
> This is what caused the use of the second slash so…
> 
> 1234567    \
> \    9012345
> 
> …and…
> 
> The quick brown fox\
>      \ jumps over the lazy dog
> 
> 
> So, my point is, if and only if we do not care about these “spaces on
> the fold” cases, we can operate with a single slash.
> 
> Cheers,
> Adrian
> 
> From: Joel Jaeggli <[email-masked]<mailto:[email-masked]>>
> Sent: 27 February 2019 06:31
> To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
> Cc: Kent Watsen <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>
> Subject: Re: [netmod] artwork folding: dual support modes?
> 
> 
> 
> On Feb 26, 2019, at 14:26, Adrian Farrel
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> Hey.
> 
> I’ve been having this discussion with Kent off-line, but thought it
> should come to the list.
> 
> I don’t think it is a good idea to have two approaches. While it would
> be relatively easy to code for both approaches, it seems to add a
> degree of confusion if both have to be handled by the same code
> (consider deciding whether leading space characters are to be retained
> or not, something that can only be decided when the first non-space
> character is found), or by having different code for the two different
> cases.
> 
> It doesn’t seem to me that both cases are needed. We can pick one or
> the other.
> 
> A single slash has been used to wrap long lines in editors and shells
> for decades at this point.
> 
> and yeah whatever it is one method seems better than two.
> 
> 
> And *if* we want to allow manual folding so that indents can be made
> to make the document more human-readable then we have to use a leading
> ‘\’ on continuation lines to show which spaces should be stripped and
> which retained.
> 
> Cheers,
> Adrian
> 
> From: netmod <[email-masked]<mailto:[email-masked]>>
> On Behalf Of Kent Watsen
> Sent: 25 February 2019 22:22
> To: [email-masked]<mailto:[email-masked]>
> Subject: [netmod] artwork folding: dual support modes?
> 
> 
> I had a chat with the tools team recently and, in the course of
> things, it was implied
> that the double backslash approach we have now was both surprising and
> non-intuitive.
> 
> This got me thinking that we may have thrown the proverbial baby out
> with the bathwater.
> That is, currently we have a header that reads:
> 
> 
>   NOTE: '\\' line wrapping per BCP XX (RFC XXXX)
> 
> So why not *also* support a header that reads (note the singe slash):
> 
> 
>   NOTE: '\' line wrapping per BCP XX (RFC XXXX)
> 
> Whereby this second form only supports the folded line continuing on
> column 1 (no indents).
> 
> Thoughts?
> 
> Kent // contributor
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 4 Mar 2019 11:08:41 +0000

But this behaviour is still different from the frequently used meaning of ‘\’ today in programming languages, which as I know it just splits lines and preserves whitespace.

YANG requires a separator character between a keyword and its argument.  What happens if the tool happens to split the line between the two of them.

E.g

                       container\

  test

After the artwork folding, this would become

                       containertest

This could be mitigated by a smarter folding tool (e.g. split before the ‘r’ or after the first space).

Or, what if the tool was being used to fold a table that was using whitespace to align the columns.  This could easily break if whitespace is stripped.

Thanks,
Rob

-----Original Message-----
From: Martin Bjorklund <[email-masked]>
Sent: 04 March 2019 08:40
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] artwork folding: dual support modes?

> stripping leading whitespace on the line following a slash.

And this is the solution that I prefer.  The reason for this is that I view examples as something that is there to illustrate some point to the reader, and I think that a prettier formatted example with less noise helps the reader.  I also think that is most cases, this works well; i.e., most cases are _not_ on the form:

   12345      78990

For this problem, I prefer a solution that is intuitive and has less noise and works for 90% of the cases, than a less intuitive solution with more noise that works for 100% of the cases.

/martin

> From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel

> To: 'Joel Jaeggli' <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>

> From: Joel Jaeggli <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

> To: Adrian Farrel <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

> Cc: Kent Watsen <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>;

> [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:

> From: netmod <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

> To: [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

> things, it was implied that the double backslash approach we have now

> was both surprising and non-intuitive.

> [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 12:49:12 +0100 (CET)

"Rob Wilton (rwilton)" <[email-masked]> wrote:
> But this behaviour is still different from the frequently used meaning
> of ‘\’ today in programming languages, which as I know it just splits
> lines and preserves whitespace.

Right, but we're not doing a programming language, we try to fit long
lines in examples into the format required by RFCs, including
indentation.  For example, suppose you have:

  Here's an example:

  foo bar baz \
  buzz

Unfolded, do you think this is:

  foo bar baz buzz

or

  foo bar baz    buzz

> YANG requires a separator character between a keyword and its
> argument.  What happens if the tool happens to split the line between
> the two of them.
> 
> 
> 
> E.g
> 
>                        container\
> 
>   test
> 
> 
> 

1.  Don't use a tool to add line breaks - remember the goal was to
    have a readable example.

2.  Don't use this alg. for YANG modules, since YANG has builtin /
    native support for splitting long lines.

> Or, what if the tool was being used to fold a table that was using
> whitespace to align the columns.  This could easily break if
> whitespace is stripped.

Don't use this alg for tables (or ascii art in general) -- it won't
help readers.

/martin

> > On Behalf Of Adrian Farrel
> 
> > From: Joel Jaeggli
> > <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
> 
> > To: Adrian Farrel
> > <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
> 
> > Cc: Kent Watsen
> > <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>;
> 
> > From: netmod
> > <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
> 
> > On Behalf Of Kent Watsen
> 
> > To:

---

From: Robert Wilton <[email-masked]>
Date: Mon, 4 Mar 2019 12:08:14 +0000

On 04/03/2019 11:49, Martin Bjorklund wrote:
> indentation.

But this does give a different meaning to a well used notation, that may 
well cause surprise and confusion.

>    For example, suppose you have:
>
>    Here's an example:
>
>    foo bar baz \
>    buzz
>

This one.  The counter example:

   foo bar baz\
   buzz

Do you think that this is:

   foo bar bazbuzz

Or

   foo bar baz  buzz

> 1.  Don't use a tool to add line breaks - remember the goal was to

No line break is added.  It was performing a line split on "container test".

> Don't use this alg for tables (or ascii art in general) -- it won't

The choice of solution seems to make it quite restricted where it can be 
validly used.  I.e. it is only safe to use to fold documents where 
whitespace has no significance, and can be arbitrarily removed from the 
folded object without changing the document's meaning.

I think that this would mean that the folding mechanism isn't safe on 
either XML or JSON documents (since whitespace is significant, e.g. 
within a string).

There seems to be a ever growing list of things that we can't safely use 
this form of artwork folding on.  Are there are any examples of stuff 
that we can safely use it on? ;-)

Thanks,
Rob

>>> wrote:

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Mar 2019 12:15:21 -0000

We can go round and round 😊

How do I fold
  foo bar baz         buzz
so that it can be unfolded?

Clearly a possibility is
  foo bar baz         \
  buzz

But what if the line length would break in the white space?
You could solve it as 
  foo bar \
  baz         buzz
which requires slightly more complex folding.

Actually, this case arises more often than you might think when the line length would cause a fold before a single space.
Thus, if the line length is 11
foo bar baz buzz
..would fold as...
foo bar baz\
 buzz
...and unfold as...
foo bar bazbuzz
...if leading spaces are stripped.

And if leading spaces are not stripped then we cannot handle manual padding for reasons of visual formatting. For example...
foo bar baz\
       buzz

Personally, I am *really* struggling to understand why we cannot use the two-slash approach only. 

Cheers,
Adrian

-----Original Message-----
From: Martin Bjorklund <[email-masked]> 
Sent: 04 March 2019 11:49
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] artwork folding: dual support modes?

  Here's an example:

  foo bar baz \
  buzz

  foo bar baz buzz

or

  foo bar baz    buzz

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 13:29:26 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> But this does give a different meaning to a well used notation, that
> may well cause surprise and confusion.
> 
> 

But note that figures in RFCs are normally indented with 3 spaces
(they _can_ be outdented, if the lines are long enough).

> Do you think that this is:

This one.

> No line break is added.  It was performing a line split on "container

I meant, don't use tools to do folding (or use a smart tool).

> The choice of solution seems to make it quite restricted where it can
> be validly used.  I.e. it is only safe to use to fold documents where
> whitespace has no significance, and can be arbitrarily removed from
> the folded object without changing the document's meaning.
> 
> either XML or JSON documents (since whitespace is significant,
> e.g. within a string).

For the use case that I envision, i.e., manually added \'s, I don't
think this is an issue.  It might be that we're trying to solve
different problems - I would like a solution that is intuitive for the
reader and has a minimal amount of noise, but I think that some others
think it is more important that tools can be used to automate the
folding process.

> There seems to be a ever growing list of things that we can't safely
> use this form of artwork folding on.  Are there are any examples of
> stuff that we can safely use it on? ;-)

Just to be clear: my preference is for a single \ as described above,
but I am ok with the solution in the current draft (an additional \ on
the next line).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 14:16:30 +0100 (CET)

"Adrian Farrel" <[email-masked]> wrote:
> Actually, this case arises more often than you might think when the
> line length would cause a fold before a single space.
> And if leading spaces are not stripped then we cannot handle manual
> padding for reasons of visual formatting. For example...
> foo bar baz\
>        buzz
> 

Maybe b/c if we do, people will start to use it and write things
like:

           "location": "file://example.org/yang/packages/ietf-routing@v\
   \1.3.1.json",
           "description": "This package defines a small sample set of I\
   \ETF routing YANG modules that could represent the set of IETF routi\
   \ng functionality that a basic IP network device might be expected t\
   \o support.",

I know, it can easily be re-written into:

           "location": "file://example.org/yang/packages\
                             \/[email-masked]",
           "description": "This package defines a small sample set \
                          \of IETF routing YANG modules that could \
                          \represent the set of IETF routing \
                          \functionality that a basic IP network \
                          \device might be expected to support.",

which is almost as readable as:

           "location": "file://example.org/yang/packages\
                              /[email-masked]",
           "description": "This package defines a small sample set \
                           of IETF routing YANG modules that could \
                           represent the set of IETF routing \
                           functionality that a basic IP network \
                           device might be expected to support.",

/martin

---

From: Robert Wilton <[email-masked]>
Date: Mon, 4 Mar 2019 13:39:36 +0000

>                             device might be expected to support.",

If I was fixing this by hand then I would probably get to this instead:

            "location": "file://example.org/yang/packages/ietf-routing@v\
    \1.3.1.json",
            "description": "This package defines a small sample set of \
    \IETF routing YANG modules that could represent the set of IETF \
    \routing functionality that a basic IP network device might be \
    \expected to support.",

I think that for the rest of that example (pages 34-37 of 
draft-rwilton-netmod-yang-packages-00), I think that the folding works 
pretty well, and the output is reasonably readable.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 Mar 2019 15:48:36 +0000

> (they _can_ be outdented, if the lines are long enough).

The days of scraping from plain-text RFCs are over [1].  Extracting, if needed at all, should be from the XML, where there are no such issues. Extracting from the plain-text output makes about as much sense as extracting from the HTML or PDF outputs.

Lossless extractions are critical for formal verifications (e.g., doctor reviews, shepherd reviews, AUTH48 reviews).   Both the double-backslash approach we currently have, and the single-backslash approach we had originally (where the continuation-line begins on column 1, as it has been in programming languages for decades) provide lossless extractions.

The double-backslash approach is ideal for when pretty-indents are desired.   The single-backslash approach is ideal for when the pretty-indents are not needed.  Both are completely valid and useful.   My contention is that we unnecessarily threw out one when reaching for the other.  

[1] https://pypi.org/project/xiax

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 17:04:23 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> The days of scraping from plain-text RFCs are over [1].  Extracting,
> if needed at all, should be from the XML, where there are no such
> issues. Extracting from the plain-text output makes about as much
> sense as extracting from the HTML or PDF outputs.

I am confused.  Are you saying that the unfolding algorithm only is
supposed to work on data extracted from the XML version of the I-D or
RFC?  If so, I think this needs to be clarified in the draft.

> Lossless extractions are critical for formal verifications (e.g.,
> doctor reviews, shepherd reviews, AUTH48 reviews).  Both the
> double-backslash approach we currently have, and the single-backslash
> approach we had originally (where the continuation-line begins on
> column 1, as it has been in programming languages for decades) provide
> lossless extractions.

... as does the single-backslash with leading space removal.

/martin

> 
> The double-backslash approach is ideal for when pretty-indents are
> desired.  The single-backslash approach is ideal for when the
> pretty-indents are not needed.  Both are completely valid and useful.
> My contention is that we unnecessarily threw out one when reaching for
> the other.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Mar 2019 16:12:26 -0000

> RFC?  If so, I think this needs to be clarified in the draft.

Quite!
If the problem is to extract from XML then there is no problem because
wrapping is not needed in the XML (unless manual wrapping has been done).
The problem to be addressed when Qin and I started this work was that
human-readable copies needed to include some form of wrapping, and we wanted
a format that made it abundantly clear that the wrapped version was not
normative, and told the reader how to unwrap in order to make valid
examples.

I fear we are losing touch with the problem statement.

Adrian

---

From: Robert Wilton <[email-masked]>
Date: Mon, 4 Mar 2019 16:24:48 +0000

The nice thing with the two slash approach is that it always works.  It 
doesn't matter whether it is text or XML, you just strip what is between 
the two slashes.

The C '\' approach doesn't really work with indentation, and I'm not 
convinced that extracting code from text RFCs is dead just yet.

Martin's strip leading white space approach doesn't safely work with 
documents that may contain meaningful white space.  Will everyone also 
include the trailing space at the end of the line before the '\' when 
required?

I still think that the double slash approach is sufficient on its own.

If we must have two, then I would suggest the double slash approach, and 
also Martin's, but perhaps use '+' instead or '\'.

Thanks,
Rob

On 04/03/2019 16:04, Martin Bjorklund wrote:
> .

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 Mar 2019 17:54:47 +0000

> On Mar 4, 2019, at 11:04 AM, Martin Bjorklund <[email-masked]> wrote:
> 

The unfolding algorithm works as long as the input == the output.  The 
problem is that plain-text RFCs introduce a lot of artifacts that makes 
lossless extraction difficult.  I don't believe we should try to design a 
solution for input != output.

Now that IETF has officially moved to XML as the sole format, there
is no longer a need to support extracting from plain-text.   In general, 
folks are advised to always extract from XML.   I support adding a 
statement to this affect.

> ... as does the single-backslash with leading space removal.

No, there are cases where this fails.  We went thru this before.  This is why
we adopted the double-backslash approach.

Kent // contributor  (also on my previous emails in this thread)

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 19:35:40 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> Now that IETF has officially moved to XML as the sole format

I'm not sure what you mean, can you provide a pointer?  AFAICT, the
latest published RFC is still only available as txt and pdf.

If the only format was XML, why bother with any line breaking at all?

>, there
> No, there are cases where this fails.  We went thru this before.

Only if you have data with > 69 spaces in a row that needs to be
preserved.

/martin

> This is why

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Mar 2019 18:49:06 -0000

> I'm not sure what you mean, can you provide a pointer?  AFAICT,
> the latest published RFC is still only available as txt and pdf.
>

I think maybe the IETF is moving towards the XML being the definitive
version of drafts and RFCs. But, it is never going to be the case that
people go to the XML to read a document. They will pick HTML or text or PDF.

So the reader will see folded lines. And the reader needs to know what a
folded line means and how to map it to reality.

Adrian

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 19:59:37 +0100 (CET)

"Adrian Farrel" <[email-masked]> wrote:
> version of drafts and RFCs.

Yes I know that.  But that's quite different from "XML as the sole
format"!

/martin

> But, it is never going to be the case that

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 Mar 2019 21:28:41 +0000

> latest published RFC is still only available as txt and pdf.

I meant that XML is the sole *input* format, per RFC 7990, but you're
right about the XML not currently being easily accessed.   I've signed
up for the IETF 104 CodeSprint to fix this, as well as to introduce
folding support into the publishing process.

> Only if you have data with > 69 spaces in a row that needs to be

More generally, anytime the fold occurs where space characters
follow.  

But why are you arguing for this? - the double-backslash approach
works great for when indents are desired.   

My interest in this thread was/is only to cover the common case 
when there are no indents, and the continuation line always begins
on column 1, in which case the 2nd backslash is unneeded and 
somewhat counterintuitive.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 22:52:23 +0100 (CET)

> More generally, anytime the fold occurs where space characters

No, b/c you wouldn't fold there.

> works great for when indents are desired.   

Let's agree that it works :)

I'm arguing that *if* we are to define two solutions, we should use
this one.  (And as I explained, my preference is this one over the
double-backslash solution, but I accept the WG consensus for the
double-backslash solution)

> somewhat counterintuitive.

But your continuation line will not start at column 1 (since artwork
is indented with 3 spaces by default).  So this solution doesn't
really work.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 Mar 2019 22:39:32 +0000

> No, b/c you wouldn't fold there.

A human wouldn't, but an automated folding solution sure could.

> double-backslash solution)

Okay, now I understand your position, but I don't agree with it and,
as mentioned before, how to support indents was thoroughly debated
before.   I can't recall if you were sailing then, but I'm guessing you
were which is why you're raising this now.

> is indented with 3 spaces by default).  So this solution doesn't

Not in the XML.   If rfcstrip/xym wish to extract from plain-text, then
they should detect the artwork-level indent/outdent and apply that
adjustment to the entire content prior to running the unfolding logic.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Sun, 24 Mar 2019 20:39:49 +0000

I’ve been thinking about Martin’s desire for the pretty single backslash approach.  I think the discussion should be about the probability of collisions (I.e., files that cannot be folded due to false positives)

Assuming 95 printable characters (127-32) plus ‘\n’, a total of 96 characters, the unconditioned probability of a given of an n-character string occurring on a line is (1/96)^n.

Here are the 3 options being discussed (please check my math!)

1. The pretty double backslash approach in the current draft
       - folds only on any column and supports indents

Scan the text content to ensure no existing lines already end with a backslash ('\') character when the subsequent line starts with a backslash ('\') character as the first non-space (' ') character.

    P(“\\\n[ ]*\\”)
      = sum of (1/96)^n for 3<=n<69
      = ∑((1÷96)^x; x; 3; 69)
      = 0.0000011421783625730994152046783625731
      ~= 1 / 1,000,000

2. The not pretty single backslash approach in I-D -06
       - folds only on max-column with no support for indents

Scan the artwork to ensure no existing lines already end with a '\' character on the desired maximum column.

     P(“.\{$maxcol-1\}\\\n”)
       = P( (not ‘\n’ for $maxcol-1 chars), followed by a “\\\n”)
       = ((1−(1÷96))^68)×(1÷96)^2
       = 0.0000532376463396105463857306859461496
        ~= 1 / 20,000

3. Martin’s pretty single backslash approach
       - folds only on any column and supports indents

Scan the artwork to ensure no existing lines already end with a '\' character OR that a white space character appears on the max column.

      P(“\\\n”) + P(“.\{$maxcol\} “)
        = (1/96)^2 + ((1−(1÷96))^69)×(1÷96)
        = 0.00516608334670744635108885960932866
        ~= 1 / 200

Note that each of these assume a long-line.  The number of long lines in a given piece of text is small, 1/100?  Thusly, while option #3 is two orders of magnitude more like than option #2, it may only be detected 1 / 200,000 text samples, that are themselves detected as needing to be folded (1/5?), so maybe one in a million text samples?

Maybe an automated folding algorithm could try #3 and, only if detecting the precondition, switch to option #1?

Kent // contributor