>>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.
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
