## Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4

 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Clark C . Evans - 2002-03-07 02:51:56 ```On Wed, Mar 06, 2002 at 12:02:26PM -0800, Brian Ingerson wrote: | On 06/03/02 10:54 -0500, Clark C . Evans wrote: | > The following is a modification of Oren's YAC#21 only | > where the default is to not allow tabs. Thus, to use | > tabs, you require an explicit #TAB directive. | | At least this one is easy to explain. (There will be a lot of | explaining to do ;) | | It resolves issues about tabs crossing the border. But those issues will | still remain when we use #TAB. If we consider the TAB to be expanded into spaces before the "parse" occurs, then this works. --- #TAB:8 crosses: | ....int flip(int x, int y) { -------->int temp = 3; -------->if(x....if(x>0) -------->-------->return x; -------->return y; ....} After "detabification" --- crosses: | ....int flip(int x, int y) { ........int temp = 3; ........if(x0) ........-------->return x; ........return y; ....} Therefore, this does solve the tab crossing the block boundary problem, no? | > #TAB:CHAR:N | > This specifies that a tab is to be treated | > as exactly N characters regardless of column; | | This is a rarer behaviour. I'd like to make it a special case. Either: | | #TAB:4:HARD Ok. | > This specifies that a tab is to be treated | > as 1..N characters required to move to the | > column that is an even multiple of N. For | > example, #TAB:COL:8 is the standard UNIX | > setting used by VI. | | This is the "normal" behaviour so just make it #TAB:4 If I saw TAB:4 (and not knowing what I know about Unix) I would assume that this means: "A tab is 4 spaces". The whole point of this was to be... explicit. Clark ```

 [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Clark C . Evans - 2002-03-06 15:53:50 ```The following is a modification of Oren's YAC#21 only where the default is to not allow tabs. Thus, to use tabs, you require an explicit #TAB directive. # YAC 22 --- location: http://www.yaml.org/yacs/022 abstract: Supporting different sized tabs, default is no tabs allowed owner: cce status: !yac/status state: new date: 2002-03-04 proposal: ] Add a #TAB directive which specifies the tab policy, without the directive the tab character is not allowed for indentation. This directive can have a few different values: #TAB:CHAR:N This specifies that a tab is to be treated as exactly N characters regardless of column; for example #TAB:CHAR:4 specifies that tabs used for indentation are to be expanded to 4 spaces. This happens to be the Visual Studio default. #TAB:COL:N This specifies that a tab is to be treated as 1..N characters required to move to the column that is an even multiple of N. For example, #TAB:COL:8 is the standard UNIX setting used by VI. If a tab is encountered in a document without the directive, then the parser must return a message which explains that tabs are not allowed, and presents these two directives allowing the user to annotate their YAML file with the appopriate tab policy. The default output of a YAML emitter is to only use spaces. rationale: ] Since different systems treat tabs differently, portability problems are a concern. Therefore, the default tab policy of YAML is conservative; don't allow them. However, for some users, their editor may make it difficult to not use tabs. In this case, the directive is available so that the tab policy is explicitly provided to the YAML processor. examples: | --- # Document where tabs are not allowed --- #TAB:CHAR:4 # Document uses 4-space tabs. --- #TAB:COL:8 # Document tabs to columns that are an even multiple of 8. -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software ```
 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Brian Ingerson - 2002-03-06 20:02:33 ```On 06/03/02 10:54 -0500, Clark C . Evans wrote: > The following is a modification of Oren's YAC#21 only > where the default is to not allow tabs. Thus, to use > tabs, you require an explicit #TAB directive. At least this one is easy to explain. (There will be a lot of explaining to do ;) It resolves issues about tabs crossing the border. But those issues will still remain when we use #TAB. > > # YAC 22 > --- > location: http://www.yaml.org/yacs/022 > abstract: Supporting different sized tabs, default is no tabs allowed > owner: cce > status: !yac/status > state: new > date: 2002-03-04 > proposal: ] > Add a #TAB directive which specifies the tab policy, without > the directive the tab character is not allowed for indentation. > This directive can have a few different values: I don't like the syntax that much. > #TAB:CHAR:N > This specifies that a tab is to be treated > as exactly N characters regardless of column; for > example #TAB:CHAR:4 specifies that tabs used > for indentation are to be expanded to 4 spaces. > This happens to be the Visual Studio default. This is a rarer behaviour. I'd like to make it a special case. Either: #HARDTAB:4 or #TAB:4:HARD > #TAB:COL:N > This specifies that a tab is to be treated > as 1..N characters required to move to the > column that is an even multiple of N. For > example, #TAB:COL:8 is the standard UNIX > setting used by VI. This is the "normal" behaviour so just make it #TAB:4 > If a tab is encountered in a document without the > directive, then the parser must return a message > which explains that tabs are not allowed, and presents > these two directives allowing the user to annotate their > YAML file with the appopriate tab policy. The default > output of a YAML emitter is to only use spaces. > rationale: ] > Since different systems treat tabs differently, portability > problems are a concern. Therefore, the default tab policy of > YAML is conservative; don't allow them. However, for some > users, their editor may make it difficult to not use tabs. In > this case, the directive is available so that the tab policy > is explicitly provided to the YAML processor. Also, special YAML editor modes will make it easier for people to edit with the TAB key. > examples: | > --- > # Document where tabs are not allowed > --- #TAB:CHAR:4 > # Document uses 4-space tabs. > --- #TAB:COL:8 > # Document tabs to columns that are an even multiple of 8. For config files without headers the assumed header could be: --- #YAML:1.0 #TAB:8 or not :) Cheers, Brian ```
 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Brian Ingerson - 2002-03-06 20:20:10 ```On 06/03/02 12:02 -0800, Brian Ingerson wrote: > On 06/03/02 10:54 -0500, Clark C . Evans wrote: > For config files without headers the assumed header could be: > > --- #YAML:1.0 #TAB:8 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. Rationale: This is an excellent compromise. Oren wants seamless interoperability between *all* YAML documents, regardless of their domain (intended purpose). Brian feels that certain uses (like config files) are securely coupled to their applications. So let the application make up the rules. And in the end, the user can always override by using #TAB. Thoughts? Cheers, Brian ```
 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Clark C . Evans - 2002-03-07 04:01:42 ```On Wed, Mar 06, 2002 at 12:20:02PM -0800, Brian Ingerson wrote: | > For config files without headers the assumed header could be: | > --- #YAML:1.0 #TAB:8 | 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. Let's say six months out the Apache group decides to use YAML. Let's say that someone sets up an Apache server on Linux, and then a month later, due to corporate policy have to move the server to WinXP. So, they copy the configuration file over, and all works well. Then one day, someone loads the configuration file into Visual Studio to make a change... they make their change and save it. All hell breaks loose. Why? Beacuse the tabs were read in as 4 spaces and then were saved as 4 spaces. The distinction between .... and --------> is now lost, items at the second level of indentation are now at the first level. Apache e-mail gets a flame for configuration files that "always break" on Winblows. Apache group decides that YAML migration wasn't such a great idea afterall. --- virtual-server: ....name: yaml.org ....ip: 209.9.30.66 ....mod-ssl: -------->cert-path: \$home/certs/yaml.crt Would become, if read-in and written out by Visual Studio... --- virtual-server: ....name: yaml.org ....ip: 209.9.30.66 ....mod-ssl: ....cert-path: \$home/certs/yaml.crt Basically... if the person is _lucky_ the "demotion" of TABS to 4 spaces will cause a duplicate key, and thus a clear parse problem. If the person is unlucky this demotion will only happen in a small area of the file and go un-detected untill a pissed-off customer calls beacuse their certificate won't be accepted. The tech-support person will run around with his head cut off for about a half day, checking the browser, checking the certs, everything, till he learns that "cert-path" must be a child of "mod-ssl" and not a sibling. At that point he'll be completely puzzled how it got demoted. And YAML will get a rightly-deserved qualification of: "not intutitive". | Rationale: | This is an excellent compromise. Oren wants seamless interoperability between | *all* YAML documents, regardless of their domain (intended purpose). Brian | feels that certain uses (like config files) are securely coupled to their | applications. So let the application make up the rules. And in the end, the | user can always override by using #TAB. This isn't a compromise as it just glosses over the TAB incompatibility issue. I don't want people to use TABS. TABS are evil since they have more than one interpretation. However, if someone must absolutely use TABS, then let's make it BUTT UGLY and very obvious when they do. Something like #TAB:EVERY-8-COLUMNS or #TAB:TREAT-AS-4-SPACES. IMHO, #TAB:4 doesn't solve the problem and having it default to EVERY-8-COLUMNS undermines the whole purpose of #TAB, which is to make the tab/space mixing policy explicit. An implicit policy is a non-starter for cross-editor compatibility. Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software ```
 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Clark C . Evans - 2002-03-07 02:51:56 ```On Wed, Mar 06, 2002 at 12:02:26PM -0800, Brian Ingerson wrote: | On 06/03/02 10:54 -0500, Clark C . Evans wrote: | > The following is a modification of Oren's YAC#21 only | > where the default is to not allow tabs. Thus, to use | > tabs, you require an explicit #TAB directive. | | At least this one is easy to explain. (There will be a lot of | explaining to do ;) | | It resolves issues about tabs crossing the border. But those issues will | still remain when we use #TAB. If we consider the TAB to be expanded into spaces before the "parse" occurs, then this works. --- #TAB:8 crosses: | ....int flip(int x, int y) { -------->int temp = 3; -------->if(x....if(x>0) -------->-------->return x; -------->return y; ....} After "detabification" --- crosses: | ....int flip(int x, int y) { ........int temp = 3; ........if(x0) ........-------->return x; ........return y; ....} Therefore, this does solve the tab crossing the block boundary problem, no? | > #TAB:CHAR:N | > This specifies that a tab is to be treated | > as exactly N characters regardless of column; | | This is a rarer behaviour. I'd like to make it a special case. Either: | | #TAB:4:HARD Ok. | > This specifies that a tab is to be treated | > as 1..N characters required to move to the | > column that is an even multiple of N. For | > example, #TAB:COL:8 is the standard UNIX | > setting used by VI. | | This is the "normal" behaviour so just make it #TAB:4 If I saw TAB:4 (and not knowing what I know about Unix) I would assume that this means: "A tab is 4 spaces". The whole point of this was to be... explicit. Clark ```
 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Brian Ingerson - 2002-03-07 03:22:36 ```On 06/03/02 21:53 -0500, Clark C . Evans wrote: > On Wed, Mar 06, 2002 at 12:02:26PM -0800, Brian Ingerson wrote: > | It resolves issues about tabs crossing the border. But those issues will > | still remain when we use #TAB. > > If we consider the TAB to be expanded into spaces > before the "parse" occurs, then this works. > --- #TAB:8 > crosses: | > ....int flip(int x, int y) { > -------->int temp = 3; > -------->if(x -------->....if(x>0) > -------->-------->return x; > -------->return y; > ....} > > After "detabification" > --- > crosses: | > ....int flip(int x, int y) { > ........int temp = 3; > ........if(x ............if(x>0) > ........-------->return x; > ........return y; > ....} > > Therefore, this does solve the tab crossing the block > boundary problem, no? I believe it was you Clark, who said that a warning must be issued if a TAB converts to spaces and crosses the border as above. In your example above, why didn't the second tab on line 7 get converted. You said expansion happens before parse. So you must expand all leading tabs. And if you do that, there will be no way to put leading tabs in blocks except by escaping, and that would ruin the point of using blocks. I say we do it as above, which means deTABing *while* parsing. And we won't warn on the crossing the border, since there isn't any ambiguity. Is there? > | > #TAB:CHAR:N > | > This specifies that a tab is to be treated > | > as exactly N characters regardless of column; > | > | This is a rarer behaviour. I'd like to make it a special case. Either: > | > | #TAB:4:HARD > > Ok. > > | > This specifies that a tab is to be treated > | > as 1..N characters required to move to the > | > column that is an even multiple of N. For > | > example, #TAB:COL:8 is the standard UNIX > | > setting used by VI. > | > | This is the "normal" behaviour so just make it #TAB:4 > > If I saw TAB:4 (and not knowing what I know about Unix) > I would assume that this means: "A tab is 4 spaces". > The whole point of this was to be... explicit. This isn't a unix thing. Every device I've seen in the world handles tabs that way. Are you sure that VisualStudio inserts a *TAB* character into the stream and then renders it as moving over 4 columns? Or does it just insert 4 *spaces* when you hit tab? If it's the latter then what's the problem? If it's the former, then that is a behaviour that I've never seen in any text processing system, and Microsoft is truly the stupidest company on the planet. (Or perhaps the evilest). Cheers, Brian ```
 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Neil Watkiss - 2002-03-07 04:00:30 ```Brian Ingerson [06/03/02 19:22 -0800]: > Are you sure that VisualStudio inserts a *TAB* character > into the stream and then renders it as moving over 4 columns? Or does it > just insert 4 *spaces* when you hit tab? If it's the latter then what's > the problem? If it's the former, then that is a behaviour that I've > never seen in any text processing system, and Microsoft is truly the > stupidest company on the planet. (Or perhaps the evilest). Neither. I was so curious I went and tried it. VS does exactly what Vi does: a TAB is a , but it's 4-aligned, not 8-aligned. 1. Create a new C++ source file (File/New...) 2. Type this: int main() { if(1){ (void)0; } 3. The means to hit return. The means VS automatically inserts an indent for you. As far as I can tell, it's a TAB, since it appears to be atomic. It displays the same as 4 spaces, but I can only put the cursor before or after it. 4. Now type this: ; 5. VS converts it to a single TAB. So there aren't any spaces, just a single indent, followed by a semicolon. 6. Now type this: ; 7. VS leaves that alone. There are four spaces on the line. They look just like the previous line, but there are four spaces, not one TAB. 8. Now type this: ; That's 6 spaces, a , a semicolon and . 9. VS converts that to two TABs and a semicolon. Conclusion: Tabs are literal tab characters in VS. They are normally displayed as 4 spaces, but they may be displayed as 1, 2, 3, or 4 characters depending on the starting column. If you hit on the keyboard, VS interprets that as "indent", and changes all spaces on the line to s, and then inserts enough spaces to maintain the same indentation level. That's something like what Emacs does -- Vi usually iterprets as a real , unless you've set 'expandtab' to true. Later, Neil ```
 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Clark C . Evans - 2002-03-07 04:16:59 ```On Wed, Mar 06, 2002 at 08:00:17PM -0800, Neil Watkiss wrote: | Neither. I was so curious I went and tried it. VS does exactly | what Vi does: a TAB is a , but it's 4-aligned, not 8-aligned. ... | Tabs are literal tab characters in VS. They are normally displayed as 4 | spaces, but they may be displayed as 1, 2, 3, or 4 characters depending on | the starting column. If you hit on the keyboard, VS interprets that as | "indent", and changes all spaces on the line to s, and then inserts | enough spaces to maintain the same indentation level. That's something like | what Emacs does -- Vi usually iterprets as a real , unless you've | set 'expandtab' to true. Thanks Neil! This is very helpful. 1. If someone views a YAML file created with VI using 4 space indentation (tabs at 8 columns) in VS then they will see/print the wrong structure, items will appear to be demoted, even though they won't. 2. When editing, if a line is touched it may compress a 4 space sequence into a tab, hence promoting a particular item, perhaps without the author knowing. 3. When someone uses _only_ tabs they are "ok". So, I see two clean options: - Forbid mixing spaces and tabs; or - Forbid tabs; or - Make the tab/space policy explicit, since VS expands tabs as a move to a column, I guess TAB:4 or TAB:8 will be ok. Yea? Clark ```
 Re: [Yaml-core] YAC#22: #TAB:COL:8 / #TAB:CHAR:4 From: Clark C . Evans - 2002-03-07 04:06:26 ```| I say we do it as above, which means deTABing *while* parsing. And we won't | warn on the crossing the border, since there isn't any ambiguity. Is there? Right, there isn't any ambiguity here. ;) | > If I saw TAB:4 (and not knowing what I know about Unix) | > I would assume that this means: "A tab is 4 spaces". | > The whole point of this was to be... explicit. | | This isn't a unix thing. Every device I've seen in the world handles | tabs that way. Are you sure that VisualStudio inserts a *TAB* character | into the stream and then renders it as moving over 4 columns? Or does it | just insert 4 *spaces* when you hit tab? If it's the latter then what's | the problem? If it's the former, then that is a behaviour that I've | never seen in any text processing system, and Microsoft is truly the | stupidest company on the planet. (Or perhaps the evilest). I don't know what editor I was using, but it's happend to me with Python code. I've read it in made a few changes and wrote it back out and it converted all of my tabs to increments of 4 spaces. This caused me to pull my hair out for at least a few minutes. I think it was Visual Studio, but ALAS, I don't have Microsoft Windows on my computer anymore so I can't test this to make sure. It may have been one of the other editors on Windows (as we tested notepad does the right thing). Best, Clark ```