On 07/10/04 12:47 -0400, Clark C. Evans wrote:
> On Thu, Oct 07, 2004 at 05:59:10PM +0200, Oren Ben-Kiki wrote:
> | The first comment is "clearly" not related to indentation. When you get
> | to '???' the tab "clearly" is related to indentation. So, the question
> | is, where do you draw the line?
> | - Restrictive (Brian's strawman, relaxed just a bit): Never allow tabs
> | as separation white space. Only allow them inside quoted and block
> | scalars. You'd have to forbid them in plain scalars, otherwise things
> | would get strange fast with tabs trailing a plain value.
> | - Relaxed: forbid tabs in indentation and in a comment line immediatly
> | following a block scalar. There's no problem allowing tabs as
> | separation white space and in all the scalar styles, including the
> | plain style.
> The 'Relaxed' case causes complexity in the productions, parsing
> code, and probably interoperability. How about Restrictive plus
> allowing tabs _following_ a # but before a new line; no point in
> forbidding tabs in a line-comment.
> | The current spec tended towards the "relaxed" option, so the set of
> | productions I'm honing uses it. Going towards the "restrictive" would
> | mean a change in the intent (in theory, it would break existing files).
> I'm all for the restricted variety (ie, allowing it in content, but
> not in separation spaces). While we are at it, can we forbid unicode
> carriage returns in separation spaces?
I am of the opinion that that *only* place to allow tabs is in the use
case of cutting and pasting a piece of structured data. Definitely
needed in the literal. Perhaps in the folded. Double quotes have a tab
escape \t so I would say don't relax my proposal for quoted stuff.
Nobody should ever type a hard tab into a yaml stream. Period.
I really want YAML to be tab free and throw errors otherwise. Read my lips ;)