RE: [Yaml-core] YAC#21: #TAB

[Oren Ben-K. <or...@ri...>]

Clark C . Evans [mailto:cc...@cl...] wrote:
> [Example of different YAML model depending on tab size]

I think that it is very likely that if the wrong tab size is used you'll get
invalid YAML very quickly... For example:

|parent:
|....child:
|!another: ]
|!....some
|........value

Is only valid if you use 4-space tabs. Using 8-space tabs you get:

parent:
    child:
        another: ]
            some
        value

Which is invalid.

> Options:
> 
>   0.  Don't worry about it, don't issue warnings and
>       use the vi view.
> 
>       Good:  Very simple for Unix-style editors.
> 
>       Bad:   People using Visual Studio will see/use
>              valid YAML files which mix spaces and
>              tabs incorrectly. 

Unless they set Visual Studio up to be TASTY (possible, just not the
default). Of course Visual Studio people aren't known for being
sophisticated in this respect...

Also, the most likely result would be that their YAML file won't parse, with
error messages about bad indentation levels.

>   1.  Throw an error when tabs and spaces are mixed,
>       provide a third party utility to "fix" invalid
>       YAML such as the example above.
> 
>       Good:  People using Visual Studio and other 
>              non-Unix style (TASTY) editors will always
>              see YAML the way the parser sees it.
> 
>       Bad:   People using VI in its default mode of
>              mixing tabs and spaces will have to learn
>              how to configure their editor to only use
>              spaces or tabs.  But, people using VI, etc.,
>              are usually a smart bunch.

People using most editors in default setting would get errors about mixing,
unless they are careful to use only tabs in tabbed files and only spaces in
spaced files, or are able to configure their editor to work around the
problem - Notepad users can't. Cut and paste between tabbed and spaced YAML
files would blow up, no matter which editor you use. In short, this has the
advantage of pissing off almost everyone :-)

>   2.  Like #1, only use a warning and assume TASTY.
> 
>       Good:  Warns vi people not to mix tabs and spaces.
>      
>       Bad:   Visual studio users will still see/use valid
>              YAML incorrectly.

Like the above, only some errors become mere warnings. Still annoying.

>   3.  Have a #TAB directive explaining the policy and 
>       allow a fixed set of policies.
> 
>       Good:  It allows the YAML parser to see what the
>              person who originally created the file and
>              put in the #TAB directive sees.
> 
>       Bad:   Other people editing the file with an editor  
>              using a different tab mixing style may see the
>              wrong structure or worse fix the structure making
>              YAML see the wrong structure (even though it thinks
>              it is getting things right since there is a #TAB).

Note that these people would be ignoring an explicit directive which is
right at the start of the document... I can see someone being bitten by this
once (First time: Hmmm, this doesn't look like valid YAML... I'll fix it...
OUCH, it stopped working?!?!? Ah, a #TAB directive; Next time: Hmmm, this
doesn't look like valid YAML... is there a #TAB directive?).

>   4.  Like #3, only use a command-line argument.
> 
>       Good:  Allows different people to use different styles
>       Bad:   People bake-in the command-line arguments and
>              thus this case is no better than 0 or 3.

And also prevents my system from being able to read your YAML file. Ugh.

> In short, I think the current state 0, is not good

Agreed.

> and I 
> think that option 1 (reject YAML with mixed tabs/spaces)
> is the only really good solution.

Options 1 and 2 prevent me from doing cut & paste between YAML files. I find
this to be unacceptable.
Option 4 prevents my YAML system from reading you YAML file. Likewise
unacceptable.

To paraphrase Holmes, once you have ruled out all the unacceptable options,
one of the remaining options, no matter how "not good", must be adopted :-)
Which means option 0 or 3. Brian and I find option 0 to be less odious than
option 3, so we suggest we give it a try for a few months. If it proves to
be unacceptable... we can move to the remaining option 3.

I don't like it but I don't see we have much choice in the matter, short of
moving ahead for option 3 right away (which is what YAC#21 was all about).
Given Python's experience, I think option 0 has enough life in it to warrant
at least test. You are the "Python representative" here... how did the
Python community deal with Visual Studio?

Have fun,

	Oren Ben-Kiki