From: Oren Ben-K. <or...@ri...> - 2002-03-07 09:37:50
|
Brian wrote: > I was half joking about this before, but now I'm very serious. > > Proposal: > For headerless documents, it is up to the application to decide the default > header (tab behaviour) for the document. I think Clark has demonstrated why this is a bad thing. So all we have to decide what the YAML-specified default is: either "tabs not allowed' or #TAB:8 (I agree with Brian the syntax should be #TAB:N or #TAB:N:HARD). This is the only difference between YAC#21 and YAC#22. My initial tendency is to go for the default being #TAB:8, simply because it is, when all is said and done, the "default" tab behavior in every "dumb" device/system such as Notepad, text viewers, printers, etc. It also makes it easier to use TASTY editors. I think YAC#22 is a bit too restrictive. That said, I can live with YAC#22. Just so you won't get the impression this settles things... About tabs crossing the indentation boundary. Consider: Original code: indent 0 ....indent 1 <--\t-->indent 2 <--\t-->....indent 3 Entered in a TASTY editor, then indented one level to the right: block: | ....indent 0 <--\t-->indent 1 <--\t-->....indent 2 <--\t--><--\t-->indent 3 De-tabbed while parsing: block: | ....indent 0 ........indent 1 ............indent 2 ........<--\t-->indent 3 De-blocked: indent 0 ....indent 1 ........indent 2 ....<\t>indent 3 Oops. Indent 3 isn't. De-tab before parsing: block: | ....indent 0 ........indent 1 ............indent 2 ................indent 3 De-blocked: indent 0 ....indent 1 ........indent 2 ............indent 3 Oops. Where did my tabs go? Now, assume that we don't allow tabs in indentation in YAML: block: | ....indent 0 ........indent 1 ....<\t>indent 2 ....<\t>....indent 3 Oops. Indent 2 and indent 3 aren't. Now, try to wrap your head around the cases where the original code uses a different tab settings than the YAML file, is pasted into it, then indented "into position", using either a TASTY or a non-TASTY editor. OOPS. I REALLY *H*A*T*E* TABS. Regardless of the tabs policy we use, our indented block mechanism just isn't up to preserving text that is tab-indented code, especially if these tabs have a different size than whatever is used by the YAML file. Thoughts? Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-03-07 22:18:21
|
Clark C . Evans wrote: > | Regardless of the tabs policy we use, our indented block mechanism > | just > | isn't up to preserving text that is tab-indented code, especially if > | these > | tabs have a different size than whatever is used by the YAML file. > > Ouch! So it sounds like we also need a warning when ever > a tab crosses the block boundary: > > WARNING: On line 4, tab crosses indentation boundary. That's already in the spec. It doesn't quite solve the problem (which is unsolvable), but it is better than nothing. > However, it seems that TABs by themselves are OK, it is > just when they are mixed with spaces for indentation that > everything gets jumbled. I'm not sure we can do much about > this but have a warning and encourage people to use just > spaces or just tabs. Hmmm. So it boils down to YAC#22 (always have a directive if you use tabs) to YAC#23 (always have a directive if you mix spaces and tabs). The problem with YAC#23 is that if I edit a YAML file without a directive, I have to find out whether it is a tabs-only or space-only file and act accordingly. Sounds trivial perhaps, but I predict it would be a major pain for "average joe": "I just opened the file in my editor, added a few lines at the end, and now it doesn't work. How was I to know???". In YAC#22, I can tell him "well, there's this hard-to-miss #TAB directive at the start - see? Well, the guy who wrote this file was lazy enough to use this tabs of this size instead of using spaces, which is the polite way to write non-private YAML. Next time, check for #TAB before you start editing, or use yaml_expand to get rid of them. BTW, complain to him to do better next time". That's simple to explain. Telling him "Well, find an indented line, move the cursor in the indentation area, if it skips more than one position, your file uses tabs so you should have also used tabs, otherwise it uses spaces so you should also have used spaces" would gain me a "Huh? could you give me that XML book again?". I might have gone with YAC#23 anyway if tab-only files were something we want to encourage. But we don't. We want to encourage *space* only files. So I don't see as an advantage the fact that we save people writing tab-only files the effort of adding a #TAB directive. On the contrary, I see it as a disadvantage. Tabs are *evil*. Anyone using them, even in a "safe" way, should pay the price of the discomfort he's inflicting on the rest of us. YAC#22 it is for me... Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-03-08 00:42:33
|
On Thu, Mar 07, 2002 at 05:18:12PM -0500, Oren Ben-Kiki wrote: | The problem with YAC#23 is that if I edit a YAML file without a directive, I | have to find out whether it is a tabs-only or space-only file and act | accordingly. Sounds trivial perhaps, but I predict it would be a major pain | for "average joe": "I just opened the file in my editor, added a few lines | at the end, and now it doesn't work. How was I to know???". Ok. This is convincing enough then. If someone uses tabs and doesn't declare them, we give them a nice error message. | I might have gone with YAC#23 anyway if tab-only files were something we | want to encourage. But we don't. We want to encourage *space* only files. So | I don't see as an advantage the fact that we save people writing tab-only | files the effort of adding a #TAB directive. On the contrary, I see it as a | disadvantage. Tabs are *evil*. Anyone using them, even in a "safe" way, | should pay the price of the discomfort he's inflicting on the rest of us. Ok. | YAC#22 it is for me... Ok. I'll go for 22; modified to use Brian's shorter tab declarations, #TAB:8, #TAB:4:HARD. So that is two votes. Brian? Clark |
From: Brian I. <in...@tt...> - 2002-03-08 07:13:24
|
On 07/03/02 19:43 -0500, Clark C . Evans wrote: > On Thu, Mar 07, 2002 at 05:18:12PM -0500, Oren Ben-Kiki wrote: > | The problem with YAC#23 is that if I edit a YAML file without a directive, I > | have to find out whether it is a tabs-only or space-only file and act > | accordingly. Sounds trivial perhaps, but I predict it would be a major pain > | for "average joe": "I just opened the file in my editor, added a few lines > | at the end, and now it doesn't work. How was I to know???". > > Ok. This is convincing enough then. If someone uses tabs > and doesn't declare them, we give them a nice error message. So this is definitely a fatal error, not a warning, right? BTW, What is the default header? --- YAML:1.0 Right? No tabs allowed? > | I might have gone with YAC#23 anyway if tab-only files were something we > | want to encourage. But we don't. We want to encourage *space* only files. So > | I don't see as an advantage the fact that we save people writing tab-only > | files the effort of adding a #TAB directive. On the contrary, I see it as a > | disadvantage. Tabs are *evil*. Anyone using them, even in a "safe" way, > | should pay the price of the discomfort he's inflicting on the rest of us. What is the final decision on "crossing the border"? Warning or Fatal? > > Ok. > > | YAC#22 it is for me... > > Ok. I'll go for 22; modified to use Brian's shorter tab > declarations, #TAB:8, #TAB:4:HARD. So that is two votes. OK. It sounds reasonable. At least nobody can say we didn't do our homework. YAML has it much rougher than Python. Of that I'm sure. I'd still like to hear your replies on my edge cases. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-03-08 13:39:09
|
On Thu, Mar 07, 2002 at 11:13:15PM -0800, Brian Ingerson wrote: | > Ok. This is convincing enough then. If someone uses tabs | > and doesn't declare them, we give them a nice error message. | | So this is definitely a fatal error, not a warning, right? Right. | Right? No tabs allowed? Right. | What is the final decision on "crossing the border"? Warning or Fatal? Hmm. That could be fatal too, especially since it involves introducing data (spaces) into the content that the user didn't specify. | > | YAC#22 it is for me... | > | > Ok. I'll go for 22; modified to use Brian's shorter tab | > declarations, #TAB:8, #TAB:4:HARD. So that is two votes. | | OK. It sounds reasonable. At least nobody can say we didn't do our homework. | YAML has it much rougher than Python. Of that I'm sure. I'd still like to | hear your replies on my edge cases. Great. Of edge cases you refer to no-tabs-in-multiline-leaves. Let's just make it a fatal error to have a tab cross the border and this is almost the same, no? Clark |
From: Brian I. <in...@tt...> - 2002-03-08 22:58:48
|
On 08/03/02 08:40 -0500, Clark C . Evans wrote: > On Thu, Mar 07, 2002 at 11:13:15PM -0800, Brian Ingerson wrote: > Great. Of edge cases you refer to no-tabs-in-multiline-leaves. Let's > just make it a fatal error to have a tab cross the border and this > is almost the same, no? I think it's exactly the same, no? Cheers, Brian |
From: Brian I. <in...@tt...> - 2002-03-08 07:01:06
|
On 07/03/02 17:18 -0500, Oren Ben-Kiki wrote: > Clark C . Evans wrote: > > | Regardless of the tabs policy we use, our indented block mechanism > > | just > > | isn't up to preserving text that is tab-indented code, especially if > > | these > > | tabs have a different size than whatever is used by the YAML file. > > > > Ouch! So it sounds like we also need a warning when ever > > a tab crosses the block boundary: > > > > WARNING: On line 4, tab crosses indentation boundary. > > That's already in the spec. It doesn't quite solve the problem (which is > unsolvable), but it is better than nothing. An alternate solution is that we never allow TABs for multiline leafs. I've proposed this twice this week as well, but got no feedback. > > However, it seems that TABs by themselves are OK, it is > > just when they are mixed with spaces for indentation that > > everything gets jumbled. I'm not sure we can do much about > > this but have a warning and encourage people to use just > > spaces or just tabs. > > Hmmm. So it boils down to YAC#22 (always have a directive if you use tabs) > to YAC#23 (always have a directive if you mix spaces and tabs). > > The problem with YAC#23 is that if I edit a YAML file without a directive, I > have to find out whether it is a tabs-only or space-only file and act > accordingly. Sounds trivial perhaps, but I predict it would be a major pain > for "average joe": "I just opened the file in my editor, added a few lines > at the end, and now it doesn't work. How was I to know???". > > In YAC#22, I can tell him "well, there's this hard-to-miss #TAB directive at > the start - see? Well, the guy who wrote this file was lazy enough to use > this tabs of this size instead of using spaces, which is the polite way to > write non-private YAML. Next time, check for #TAB before you start editing, > or use yaml_expand to get rid of them. BTW, complain to him to do better > next time". That's simple to explain. > > Telling him "Well, find an indented line, move the cursor in the indentation > area, if it skips more than one position, your file uses tabs so you should > have also used tabs, otherwise it uses spaces so you should also have used > spaces" would gain me a "Huh? could you give me that XML book again?". > > I might have gone with YAC#23 anyway if tab-only files were something we > want to encourage. But we don't. We want to encourage *space* only files. So > I don't see as an advantage the fact that we save people writing tab-only > files the effort of adding a #TAB directive. On the contrary, I see it as a > disadvantage. Tabs are *evil*. Anyone using them, even in a "safe" way, > should pay the price of the discomfort he's inflicting on the rest of us. > > YAC#22 it is for me... > > Have fun, > > Oren Ben-Kiki > > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Clark C . E. <cc...@cl...> - 2002-03-08 13:31:10
|
On Thu, Mar 07, 2002 at 11:00:59PM -0800, Brian Ingerson wrote: | An alternate solution is that we never allow TABs for | multiline leafs. I've proposed this twice this week as | well, but got no feedback. It seems a bit arbitrary. It does solve the boundary problem though, doesn't it. It just doesn't solve the demotion problem. IT seems YAC#22 solves demotion, but doesn't solve the boundary problem... I don't know. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Oren Ben-K. <or...@ri...> - 2002-03-07 22:27:44
|
I wrote: > In YAC#22, I can tell him "well, there's this hard-to-miss #TAB > directive at the start - see? Well, the guy who wrote this file was lazy > enough to use this tabs of this size instead of using spaces, which is > the polite way to write non-private YAML. Next time, check for #TAB > before you start editing, or use yaml_expand to get rid of them. BTW, > complain to him to do better next time". Or: "See, you used tabs for indentation and didn't add a #TAB directive to the document. First, don't use tabs, it isn't nice. Second, if you have to, put a #TAB directive so YAML would know what you had in mind. Not everyone uses 5-space tabs, you know." Either way, it is easier to justify than the YAC#23 case. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-03-07 13:48:53
|
On Thu, Mar 07, 2002 at 04:36:19AM -0500, Oren Ben-Kiki wrote: | Brian wrote: | > I was half joking about this before, but now I'm very serious. | > | > Proposal: | > For headerless documents, it is up to the application to decide the | > default header (tab behaviour) for the document. | | I think Clark has demonstrated why this is a bad thing. Right. It's not the application's choice, it is the person who fills out the configuration file. Default configuration files should just use spaces to be the most compatible. | So all we have to decide what the YAML-specified default is | either "tabs not allowed' or #TAB:8 (I agree with Brian the | syntax should be #TAB:N or #TAB:N:HARD). This | is the only difference between YAC#21 and YAC#22. If we have a default of #TAB:8, then I don't see the point in having #TAB at all. IMHO, if tabs are not forbidden then there is no point in having a directive to specify non-default behavior... too confusing. The goal is to get the user to have an error message like: By default TABS are not allowed in YAML files since they mean different things to different editors. If you are certain that this file will not be viewed, printed, edited by another editor there are two tab-behavior directives available. #TAB:N means that a tab will be replaced by 1..N spaces to move to a column evenly divisible by N. #TAB:N:HARD means that a tab will be replaced by N spaces regardless of column. Most editors use #TAB:8, but there are enough editors that don't use this standard to cause problems, which is why tab useage must be explicitly declared in YAML. We recommend that you avoid tabs and configure your editor to just use spaces, this gives the greatest interoperability between systems. It's a bit long-winded, but after they read it they will at least understand the problem with TABS. I'll go for either of the three options: 1. We use 8 column tabs and suffer the problems when people load YAML into Visual Studio and don't see the structure right. 2. We forbid tabs altogether, this is the simplest.. 3. We forbid tabs unless there is a #TAB directive. Options that I'm now convinced are unworkable: 1. We have a command line argument, or the application determines which tab method to use. 2. We default to TAB:8, but include a directive to specify other behavior. This is confusing. 3. Just banning the mixing of TABs and SPACEs. This doesn't allow for cut'n'paste, also it runs against vi's default behavior. Further, it's kinda arbitrary. | My initial tendency is to go for the default being #TAB:8, simply because it | is, when all is said and done, the "default" tab behavior in every "dumb" | device/system such as Notepad, text viewers, printers, etc. It also makes it | easier to use TASTY editors. I think YAC#22 is a bit too restrictive. That | said, I can live with YAC#22. I think YAC#22 is a bad idea. If we go #TAB:8 default, then let's make this the _only_ tab policy it's too confusing otherwise. Clark |
From: Clark C . E. <cc...@cl...> - 2002-03-07 13:58:19
|
Ok. I just thought of another option... We go with TAB:8 as the _only_ tab policy and have the parser/emitter give a warning message so that people clearly know that using TABs is bad policy. The default emitter then adds the following comment line to the top of every YAML file just to be sure: # This YAML file treats a TAB as 1..8 spaces such that # the result lands on a column evenly divisible by 8. Then we put up a big warning sign on our FAQ and main website and we warn anyone who uses YAML that TABs have teeth. Clark |
From: Clark C . E. <cc...@cl...> - 2002-03-07 14:18:39
|
Ok. I have a refinement! The _only_ tab/space mixing policy is TAB:8, aka TASTY. YAML emitters then either use tabs or spaces depending on the user's choice and _never_ produce YAML that mixes tabs and spaces. If tabs and spaces are _mixed_ in an input file, the parser must produce this warning: WARNING: This file's indentation mixed tabs and spaces. Mixing of tabs and spaces may not be portable since different editors may have different policies. In a YAML file, tabs are mixed with spaces by treating a tab as 1..8 spaces such that the resulting column is evenly divisible by 8 (standard unix treatment).a The goal of this warning is to irritate the user enough that they stop mixing tabs and spaces, thus it should not be suppressable else we will cause ourselves a big headache down the road. Further, We then put up a big warning sign on our website and FAQ describing how TABs and SPACE mixing can cause compatibility problems with various editors. IMHO, this seems the simplest. Our problem isn't with TABS, it's with the Mixing of TABS with SPACEs. Best, Clark |
From: Brian I. <in...@tt...> - 2002-03-08 06:43:53
|
On 07/03/02 09:19 -0500, Clark C . Evans wrote: > Ok. I have a refinement! > > The _only_ tab/space mixing policy is TAB:8, aka TASTY. > YAML emitters then either use tabs or spaces depending on > the user's choice and _never_ produce YAML that mixes tabs > and spaces. If tabs and spaces are _mixed_ in an input > file, the parser must produce this warning: I would prefer that YAML emitters never emit tabs. > WARNING: This file's indentation mixed tabs and spaces. Mixing > of tabs and spaces may not be portable since different editors > may have different policies. In a YAML file, tabs are mixed with > spaces by treating a tab as 1..8 spaces such that the resulting > column is evenly divisible by 8 (standard unix treatment).a > > The goal of this warning is to irritate the user enough that they > stop mixing tabs and spaces, thus it should not be suppressable else > we will cause ourselves a big headache down the road. Further, > We then put up a big warning sign on our website and FAQ describing > how TABs and SPACE mixing can cause compatibility problems with > various editors. > > IMHO, this seems the simplest. Our problem isn't with TABS, it's > with the Mixing of TABS with SPACEs. Clark. How many times do I need to repeat myself? We *can't* encode YAML with just TABS. That means we must either have mixing or disallow tabs. The reason is because of our explicit multiline indentation notation: foo: |3 bar: ]\5 etc. This is in terms of spaces not TABs. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-03-08 13:34:48
|
| Clark. How many times do I need to repeat myself? We *can't* encode YAML with | just TABS. That means we must either have mixing or disallow tabs. | | The reason is because of our explicit multiline indentation notation: | | foo: |3 | bar: ]\5 | | etc. This is in terms of spaces not TABs. Ok. ;) Clark |
From: Brian I. <in...@tt...> - 2002-03-07 14:15:24
|
On 07/03/02 08:49 -0500, Clark C . Evans wrote: > On Thu, Mar 07, 2002 at 04:36:19AM -0500, Oren Ben-Kiki wrote: > | Brian wrote: > | > I was half joking about this before, but now I'm very serious. > | > > | > Proposal: > | > For headerless documents, it is up to the application to decide the > | > default header (tab behaviour) for the document. > | > | I think Clark has demonstrated why this is a bad thing. > > Right. It's not the application's choice, it is the person > who fills out the configuration file. Default configuration > files should just use spaces to be the most compatible. +1 > By default TABS are not allowed in YAML files > since they mean different things to different > editors. If you are certain that this file will > not be viewed, printed, edited by another editor > there are two tab-behavior directives available. > #TAB:N means that a tab will be replaced by 1..N > spaces to move to a column evenly divisible by N. > #TAB:N:HARD means that a tab will be replaced by > N spaces regardless of column. Most editors use > #TAB:8, but there are enough editors that don't > use this standard to cause problems, which is why > tab useage must be explicitly declared in YAML. > We recommend that you avoid tabs and configure > your editor to just use spaces, this gives the > greatest interoperability between systems. This is nice. > It's a bit long-winded, but after they read it they > will at least understand the problem with TABS. I'll > go for either of the three options: > > 1. We use 8 column tabs and suffer the problems > when people load YAML into Visual Studio and > don't see the structure right. And the other embedding problems Oren pointed out. > 2. We forbid tabs altogether, this is the simplest.. Yes, but if we do this people either subvert it with preprocessors (which would suck) or abandon YAML (even worse) > > 3. We forbid tabs unless there is a #TAB directive. The reasonable compromise. > > Options that I'm now convinced are unworkable: > > 1. We have a command line argument, or the > application determines which tab method to use. > > 2. We default to TAB:8, but include a directive to > specify other behavior. This is confusing. > > 3. Just banning the mixing of TABs and SPACEs. This > doesn't allow for cut'n'paste, also it runs against > vi's default behavior. Further, it's kinda arbitrary. And explicit block indentation simply doesn't work with this. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-03-07 14:42:05
|
On Thu, Mar 07, 2002 at 06:15:17AM -0800, Brian Ingerson wrote: | > By default TABS are not allowed in YAML files | > since they mean different things to different... | | This is nice. Cool. I was thinking, we only need to require the directive when tabs and spaces are "mixed". Thus, I could combine this message with the previous message. | > 3. We forbid tabs unless there is a #TAB directive. | | The reasonable compromise. A weaker compromise which may work... is to forbid the mixing of tabs and spaces unless there is a #TAB directive. A YAML file with just tabs or just spaces is unambiguous. ;) Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Brian I. <in...@tt...> - 2002-03-08 06:46:59
|
On 07/03/02 09:43 -0500, Clark C . Evans wrote: > On Thu, Mar 07, 2002 at 06:15:17AM -0800, Brian Ingerson wrote: > | > By default TABS are not allowed in YAML files > | > since they mean different things to different... > | > | This is nice. > > Cool. I was thinking, we only need to require the > directive when tabs and spaces are "mixed". Thus, I > could combine this message with the previous message. No. You need this directive whenever there are TABs in the indentation, period. > > | > 3. We forbid tabs unless there is a #TAB directive. > | > | The reasonable compromise. > > A weaker compromise which may work... is to forbid the > mixing of tabs and spaces unless there is a #TAB directive. > A YAML file with just tabs or just spaces is unambiguous. Nope. Cheers, Brian |
From: Brian I. <in...@tt...> - 2002-03-07 14:04:10
|
On 07/03/02 04:36 -0500, Oren Ben-Kiki wrote: > I think Clark has demonstrated why this is a bad thing. So all we have to > decide what the YAML-specified default is: either "tabs not allowed' or > #TAB:8 (I agree with Brian the syntax should be #TAB:N or #TAB:N:HARD). This > is the only difference between YAC#21 and YAC#22. I'll vote for "tabs not allowed". (See below) > > My initial tendency is to go for the default being #TAB:8, simply because it > is, when all is said and done, the "default" tab behavior in every "dumb" > device/system such as Notepad, text viewers, printers, etc. It also makes it > easier to use TASTY editors. I think YAC#22 is a bit too restrictive. That > said, I can live with YAC#22. > > I REALLY *H*A*T*E* TABS. Then let's work hard to abolish them :) Let's definitely require that emitters never use tabs for indentation, even if the #TAB parsing is emitted. > Regardless of the tabs policy we use, our indented block mechanism just > isn't up to preserving text that is tab-indented code, especially if these > tabs have a different size than whatever is used by the YAML file. That's why I have always been indenting YAML blocks at increments of 8. So that clever TASTY editors don't screw me over. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-03-07 14:29:35
|
On Thu, Mar 07, 2002 at 06:04:04AM -0800, Brian Ingerson wrote: | > I REALLY *H*A*T*E* TABS. | | Then let's work hard to abolish them :) | | Let's definitely require that emitters never use tabs for indentation, even | if the #TAB parsing is emitted. Here is my preference order: 1. Forbid tabs unless there is a #TAB directive (YAC#23) 2. Forbid tabs in all cases 3. Allow tabs, but produce mandatory warning if tab/space mixing occurs. In every case we should put links to YAML modes for each editor on our website and have error/warning messages point to this location. yaml.org/editor/ could be a list of editors and yaml.org/editor/vi would be the mode for vi, for example. And in every case, emitters should never use tabs! Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Clark C . E. <cc...@cl...> - 2002-03-07 15:34:18
|
| Just so you won't get the impression this settles things... | About tabs crossing the indentation boundary. | | indent 0: | ....indent 1: | <--\t-->indent 2: | <--\t-->....indent 3: ... | indent 0 | ....indent 1 | ........indent 2 | ....<\t>indent 3 ... | Regardless of the tabs policy we use, our indented block mechanism just | isn't up to preserving text that is tab-indented code, especially if these | tabs have a different size than whatever is used by the YAML file. Ouch! So it sounds like we also need a warning when ever a tab crosses the block boundary: WARNING: On line 4, tab crosses indentation boundary. However, it seems that TABs by themselves are OK, it is just when they are mixed with spaces for indentation that everything gets jumbled. I'm not sure we can do much about this but have a warning and encourage people to use just spaces or just tabs. Best, Clark |