Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> 
> >>But with variable placement of the '\' character you can do:
> >>
> >>        This very long line happens to have a space character \
> >>        immediately after the fold column.";
> >>
> 
> This would not work, since the line is one character too long
> 
> 
> >> or
> >>
> >>        This very long line happens to have a space \
> >>        character immediately after the fold column.";
> 
> This is legal, but is in the realm of manual-folding, or "semi-manual
> folding", for what you do with your preprocessing-scripts.
> 
> 
> >>so I'm not sure that disallowing space at the fold column is a
> >> problem.
> >>
> >> Note that even with this, your original "one-liner sed" still produces
> >> valid results, so if you just want a simple folding program you can
> >> use that.
> 
> True.  We could define a feature-rich format, for which the existing
> script only-supports a lowest common denominator.  From a folding
> perspective, that might be okay, but from an unfolding perspective,
> it could not be used to unfold any folded-artwork, and so I'd push
> to fix the script to unfold any input.
> 
> 
> >> The problem is that this does not work in cases where there are a 
> >> lot of spaces - particularly where there are more than 'line-length'
> >> spaces in a row, in the middle of the line.
> 
> Right, so if the input was something like an empty table row:
> 
>        +------------------+------------------+-----------------+------etc.
>        |                  |                  |                 |
> 
> Or a snippet of a UML diagram where the line is a 100% blank:
> 
>                                                                       etc.
> 
> Allowing arbitrary per-line indent makes decoding these cases ambiguous.

Yes, but is this really a problem?  I don't think it would be a good
idea to take a very width ascii-table and fold it like this - the
point of having a ascii table is to make the data easy to read; that
won't be the case if the table is folded.

IMO the problem we want to solve is folding when there is no
alternative.  E.g., XML or JSON snippets with long identifier names,
source code snippets etc.



/martin



> 
> 
> 
> If the goal is to have a pair or rules like:
> 
>   1. Any line ending with "\\n" is considered folded, regardless of the column.
>   2. The original/source artwork MUST NOT have any lines ending with '\' char.
> 
> which would support your semi-manual folding scripts, I think it is possible
> (TBD), but it would entail having a fixed indent rule (e.g., some hardcoded
> column number, or always use the same indent as previous line, or always use
> the same indent as the previous line plus some fixed offset).  Given a clear
> rule, the unfolding alg can chomp just the right amount of whitespace out,
> leaving any remaining whitespace, for a loss-less decode.
> 
> Alternatively, we can have arbitrary per-line indent, but then we need to 
> have a fixed fold-column, or assert that the source artwork has no whitespace
> where the fold begins, which means blank lines could never be supported.  This
> was mentioned above also.
> 
> 
> PS: Regarding Rob's desire for 120-char line lengths, I forgot to mention
> before that the current I-D doesn't specify a maximum.  It only says that
> 69 is the default, and 53 is the minimum, so 120 is fine.
> 
> 
> Kent // contributor
> 
> 
>