From: Oren Ben-K. <or...@ri...> - 2002-02-26 15:02:33
|
Steve Howell [mailto:sh...@zi...] wrote: > I will give the tab-hater's view. Spacers are unambiguous, > so they are always better for the reader than the tabs. I > always set my editor to save spaces. When I receive code or > data from other folks that has tabs in it, I never know > whether their tabs are 4 or 8 spaces. Agreed. However, we figured disallowing tabs would confuse people... > Even though YAML has a default setting of 8 spaces, I > think we should require the #TAB directive in any file that > has tabs. Hmmm. So you suggest that tabs would be invalid unless there's an explicit TAB directive - as opposed for tabs having a default size of 8? Interesting notion... I'll have to think it over. Thoughts? > If we discourage folks from using tabs, ... by requiring them to add a TAB directive ... > then it makes it marginally easier to > write one-off tools that look for stuff in YAML files without > actually parsing > it. I don't know; your one-off tools would still have to handle the case where tabs are present. Not that it is such a hardship to parse directives, without parsing the whole YAML structure... > Also, if folks want to make round-tripping YAML tools, > then they can just save the indent levels of branches, > not leafs. How does that help? The same tab problem exists for all node kinds. Besides, the indentation level is explicitly a syntax issue, in general round-tripping YAML is under no obligation to preserve it anyway. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-02-28 07:43:54
|
Clark C . Evans [mailto:cc...@cl...] wrote: > Position: | > YAML should make it illegal to mix tabs and spaces > for indentation within a file. It should be a syntax > error so that the user can fix it. So... every document would be either tab-based or space based - but it would be OK, in a document stream, to have one document using tabs and another using spaces. Hmmm. Tab size becomes a non-issue. Dumb editors work if you are mildly careful... smart editors work by definition :-) > This position does not prevent a YAML parser from dealing > with illegal files which mix TABs and spaces in an intelligent > manner; however, such mitigation methods should be explicit > via a parser parameter. Such mixed handling methods should > include: (a) tabs are replaced with a number of spaces which > brings the current column to a mod of N, where N is usually 8 > and sometimes 4, (b) tabs are replaced with N spaces where N > is usually 8 but often 4, (c) tabs and spaces are treated > literally, and indentation must match exactly. So, we'd add something like the above paragraph to the spec, and keep the productions clean in terms of spaces-only or tabs-only? > Thus, we get the best of both worlds. For those that use TABS, > YAML doesn't care. It shouldn't. For those that use SPACES, > we are very flexible, and once again, we don't care. I'd be flexible for both tabs and spaces - no harm in it. > In short, I'm pretty opposed to a #TAB directive or anything > which would cause or sanction TABS and SPACES to be mixed > within a YAML file. If someone does the mixing.. they should > pay the price with a command line argument. Note, that on > a given platform, the mixing option could be saved. However, > this should be *explicit* to avoid problems. This would only work locally; when they send the file to anyone else, they'd have to attach this information to the file. If there was a #TAB:<policy> directive where <policy> was one of LITERAL/MOD-<N>/EXPAND-<N> then this information would be carried in the file itself. > | > Even though YAML has a default setting of 8 spaces, I > | > think we should require the #TAB directive in any file that > | > has tabs. > > | Hmmm. So you suggest that tabs would be invalid unless there's > | an explicit TAB directive - as opposed for tabs having a default > | size of 8? Interesting notion... I'll have to think it over. > > Kinda draconian. As originally put, yes. But - what if the rule is that it is an error to *mix* spaces and tabs unless there's a TAB directive? That means that if one is careful, there's no need for a directive; if you want to get tricky, you can but you have to explicitly declare what you are doing. We can also add wording to the effect that emitters "should not" mix spaces and tabs because this reduces the ability of people to edit YAML documents in different editors. The down side is that every implementation would have to implement every policy - but that's something you recommend anyway... and, of course, that this does sanction the practice - even if it is discouraged. Hmmm. Tell you what. How about we go with Clark's notion, and keep this option as a second line of defense? We can add the following wording to the spec: <as Clark wrote above>... Many editors have a fixed method of handling TAB characters, and very few allow some way of configuring this method according to markers in the edited file. Hence, to allow YAML files to be editable everywhere, YAML does not provide a standard way (such a directive) for providing this parser parameter. If it turns out that mixing TABs and spaces is a major use case, this decision would have to be reconsidered. Thoughts? Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-03-01 23:13:28
|
Brian Ingerson wrote: > Sorry to get in late on this thread. (But sometimes that's the best way. > Let everyone else do the fighting ;) Right :-) > I could go on about th one for a while, but I'll start by aserting that > I am firmly opposed to raising this or any other *syntax* related yacs > at this time. We are supposed to be frozen. > ... > The "next 8" rule is the best real world compromise we can come up with. > (It also happens to be Python's rule.) > > So let's stick to our guns and readdress this issue later. I guess so. I find the point about Python changing their policy for this based on real-world experience to be rather convincing. I wonder if there's any record of the process they went through - and how exactly do they deal with Visual Studio - if they do :-) Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-03-03 01:22:21
|
On 01/03/02 18:13 -0500, Oren Ben-Kiki wrote: > Brian Ingerson wrote: > > Sorry to get in late on this thread. (But sometimes that's the best way. > > Let everyone else do the fighting ;) > > Right :-) > > > I could go on about th one for a while, but I'll start by aserting that > > I am firmly opposed to raising this or any other *syntax* related yacs > > at this time. We are supposed to be frozen. > > ... > > The "next 8" rule is the best real world compromise we can come up with. > > (It also happens to be Python's rule.) > > > > So let's stick to our guns and readdress this issue later. > > I guess so. I find the point about Python changing their policy for this > based on real-world experience to be rather convincing. I wonder if there's > any record of the process they went through - and how exactly do they deal > with Visual Studio - if they do :-) I was actually wrong about this assertion. Paul Prescod was over at my place this week and I asked him about it. Apparently Python has always had its current rules for whitespace. In addition there has been an open proposal to change over to "no mixing" for a long time, but Guido has never acted upon it. I asked Paul what his opinion was. He was more in favor of "no mixing tabs and spaces within a file (stream)". We could actually allow it to change between documents in a stream. I think I could live with "no mixing". It's just a different philosophy. Stricter might be better. I'm opposed to beaking the spec freeze, but hey, we've done it before :) Let me reproof Clark's proposal and I'll get back to you. Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2002-03-03 08:34:43
|
Brian wrote: > I rather like letting the application make its whitespace > rules, rather than > letting the document author have the control/burden. I disagree because this means that interoperability is shot. Back to basic principles: Goal 1: Any YAML document should work in any YAML system, without having to add all sort of external parser flags. Therefore: *If* we allow mixing spaces and tabs, *and* allow more than one method of interpreting tabs, there should be a directive for specifying this method. Goal 2: YAML's default tab interpretation should be the most widely used one. Therefore: *If* mixing spaces and tabs is allowed *without* a directive, the default interpretation of tabs should be 8 spaces (like notepad, and your printer, and your type/more/page/less program, and your console/terminal program, etc.) Whatever we decide, I feel strongly about the two "therefore"s above. Goal 3: Editing YAML should be easy in all editors. That's a tricky one. Let's break it into pieces: Goal 3.1: Using any editor in its default setting should cope with any YAML. Therefore: We should not allow mixing spaces and tabs. Goal 3.2: Using my editor in its default setting should allow trivial editing for my YAML. Therefore: We should allow mixing spaces and tabs, with a #TAB directive specifying the tab size. Hmmm. Two contradictory conclusions... We have the following options: A. If we don't allow mixing spaces and tabs, 3.1 is achieved in all editors and 3.2 fails in all editors. B. If we allow mixing spaces and tabs with 8-space tabs only, 3.1 and 3.2 are both achieved in 8-space tab editors and fail in 4-space tab editors. C. If we allow mixing spaces and tabs with flexible (directive) size, 3.1 and 3.2 are both achieved in an editor with the correct setting and fail in an editor with an incorrect setting. There's no good way to choose between these. In such a case, I think the spec should simply not make a choice. Therefore: - Add the following wording "Emitters should not mix spaces and tabs. This allows the YAML document to be correctly viewed and edited in any text processing systems, regardless of its notion of tab size". - Keep the default interpretation of 8-space tabs. Add the wording "This interpretation is chosen because it is used by the vast majority of text processing systems, e.g. text viewers, printers, simple editors etc.". And one of: - Allow a #TAB directive to override this. Add the wording "If ease of work with specific editor(s) is an overriding concern, the #TAB directive may be used at the cost of reduced ease of editing/viewing/printing in other systems. Note that many editors provide an option for converting each pressing of the tab key into a configurable number of spaces. Where available, turning on this option is preferred to specifying a #TAB directive as it provides the same ease of work without paying the cost of reduced ease of editing/viewing/printing the file in other systems." And let the author of the document decide on his favorite tradeoff. In short, YAC#21 :-) Or, assume the following ["The Assumption of Smart Tabs for YAML", known as "TASTY"]: - Every editor either uses strict 8-space tabs or provides an option for expanding tab key press to N!=8 spaces on input *and* still interpret existing TAB characters as 8 spaces. - Do *not* add a #TAB directive. Instead add the wording "Note that many editors provide an option for converting each pressing of the tab key into a configurable number of spaces. This allows easy editing of YAML files in such editors using arbitrary indentation levels without mixing spaces and tabs." This violates 3.2 ("Using default settings") but satisfies a weaker form of it ("Using *some* settings). That may be enough... Note that Notepad, VIM, EMACS and Visual Studio are all TASTY. I dare say all editors should be. does anyone know of a non-TASTY editor? So... my tendency right now is to keep the spec as it is. I'm also willing to adopt YAC#21 (#TAB directive) if not enough editors are TASTY or if setting the editor to a non-standard setting is too much of a pain for users (we could set up a HOWTO page for editing YAML in popular editors to help this). I'm against disallowing mixing spaces and tabs (it doesn't solve enough of the problem) and against allowing non 8-space tabs without a directive (destroys interoperability). Thoughts? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-03-03 14:38:10
|
On 03/03/02 03:34 -0500, Oren Ben-Kiki wrote: > So... my tendency right now is to keep the spec as it is. I'm also willing > to adopt YAC#21 (#TAB directive) if not enough editors are TASTY or if > setting the editor to a non-standard setting is too much of a pain for users > (we could set up a HOWTO page for editing YAML in popular editors to help > this). I'm against disallowing mixing spaces and tabs (it doesn't solve > enough of the problem) and against allowing non 8-space tabs without a > directive (destroys interoperability). Thanks for a very insightful analysis! And thanks for a new acromyn. I love it :) > Thoughts? Here's mine. I'm not sold on the business of interoperability. (Please sell me). It seems to me that YAML documents fall within certain domains. I don't see why my config file needs to be interoperable with your document processor. I guess the catch 22 situation is that the most common domain for humans editing YAML is in "config" files. That's exactly where you would like to avoid having a #TAB directive. (or a header at all) --- Here's a common situation where TASTY editors bite you. Suppose you type the following by hand: --- comment: some TASTY embedded YAML :) yaml: | --- foo: - bar - baz ... You end up with "ambiguous tab converted to spaces" warning messages because the TASTY editor puts tabs in the last two lines. I suppose that's not so bad. --- All in all, I'll have to agree with Oren's summary above. Keeping things asis will get us the farthest, IMO. Adding a #TAB sucks, but then again, so does the concept of 4 (or even 6) space TABs. Let 'em get what they deserve :) --- I'm going to start writing a YAML mode for vim that does auto-indenting with spaces. I'm starting to use YAML as code in Perl. Since Perl allows data to easily be used as code, YAML is the perfect way to organize repetitive or cumbersome parts of my scripts. I envision that Perl and Python may one day have language level support for YAML. Since vim's Perl mode is TASTY, I'm wondering if vim can support multiple syntaxes within a file. I've heard that emacs can. Cheers, Brian |
From: Neil W. <neilw@ActiveState.com> - 2002-03-03 20:35:50
|
Brian Ingerson [03/03/02 06:38 -0800]: > I'm going to start writing a YAML mode for vim that does auto-indenting with > spaces. Try starting from these: http://ttul.org/~nwatkiss/vim/indent/yaml.vim http://ttul.org/~nwatkiss/vim/syntax/yaml.vim Stick them in your home directory here: ~/.vim/indent/yaml.vim ~/.vim/indent/yaml.vim And then make sure ~/.vim/filetype.vim contains this: augroup filetypedetect au BufNewFile,BufRead *.yaml,*.yml setf yaml augroup END Then edit or create a new YAML file and see if you like it. It's still very simplistic, but it knows about autoindenting, and uses spaces not tabs. > I'm starting to use YAML as code in Perl. Since Perl allows data to easily be > used as code, YAML is the perfect way to organize repetitive or cumbersome > parts of my scripts. I envision that Perl and Python may one day have > language level support for YAML. Would you mind showing me an example? That sounds pretty cool. > Since vim's Perl mode is TASTY, I'm wondering if vim can support > multiple syntaxes within a file. I've heard that emacs can. Yes. In fact, Perl's vim syntax already does this. Just do this to your ~/.vimrc file: let perl_include_pod = 1 Then when you edit Perl scripts, the embedded Pod sections are highlighted using the Pod syntax. The C++ and XS modes also include C. It's done a lot. Later, Neil |
From: Neil W. <neilw@ActiveState.com> - 2002-03-03 22:21:31
|
Neil Watkiss [03/03/02 12:35 -0800]: > Stick them in your home directory here: > > ~/.vim/indent/yaml.vim > ~/.vim/indent/yaml.vim s/indent/syntax/ For the second one. Oops! Later, Neil |
From: Brian I. <in...@tt...> - 2002-03-05 02:25:46
|
On 03/03/02 12:35 -0800, Neil Watkiss wrote: > Brian Ingerson [03/03/02 06:38 -0800]: > > I'm going to start writing a YAML mode for vim that does auto-indenting with > > spaces. > > Try starting from these: > > http://ttul.org/~nwatkiss/vim/indent/yaml.vim > http://ttul.org/~nwatkiss/vim/syntax/yaml.vim You are a most righteous dude! |
From: Brian I. <in...@tt...> - 2002-03-05 02:45:24
|
On 03/03/02 12:35 -0800, Neil Watkiss wrote: > Brian Ingerson [03/03/02 06:38 -0800]: > Yes. In fact, Perl's vim syntax already does this. Just do this to your > ~/.vimrc file: > > let perl_include_pod = 1 > > Then when you edit Perl scripts, the embedded Pod sections are highlighted > using the Pod syntax. The C++ and XS modes also include C. It's done a lot. I guess we need to give vim something to key off of. Like =head, =cut. I use '...' as a convention to mean YAML end of stream, in my writings and in ysh. I wish his worked: YAML::Load <<...; --- YAML:1.0 foo: bar ... It doesn't. But this does: YAML::Load <<___; --- YAML:1.0 foo: bar ___ If we used that as a convention, we could mix vim highlighting pretty easily I'll bet. Cheers, Brian |
From: Neil W. <neilw@ActiveState.com> - 2002-03-05 03:29:39
|
Brian Ingerson [04/03/02 18:43 -0800]: > I wish his worked: > > YAML::Load <<...; > --- YAML:1.0 > foo: bar > ... > > It doesn't. But this does: YAML::Load <<'...'; --- YAML:1.0 foo: bar ... > If we used that as a convention, we could mix vim highlighting pretty easily > I'll bet. Sure. You could probably even make it configurable, somehow: # vim: yaml-start="..." Later, Neil |
From: Ron P. <rp...@ma...> - 2002-03-03 19:41:25
|
At 06:38 AM 03/03/02 -0800, Brian Ingerson wrote: >Since vim's Perl mode is TASTY, I'm wondering if vim can support >multiple syntaxes within a file. I've heard that emacs can. > >Cheers, Brian The March 2002 issue of Linux Magazine has an article on combining Vim's syntax definitions. The .vim file can be found here: http://www.linux-mag.com/downloads/2002-03/scmpl.vim Ron |
From: Brian I. <in...@tt...> - 2002-03-05 02:24:50
|
On 03/03/02 14:49 -0500, Ron Pero wrote: > At 06:38 AM 03/03/02 -0800, Brian Ingerson wrote: > >Since vim's Perl mode is TASTY, I'm wondering if vim can support > >multiple syntaxes within a file. I've heard that emacs can. > > > >Cheers, Brian > > The March 2002 issue of Linux Magazine has an article on combining Vim's > syntax definitions. The .vim file can be found here: > http://www.linux-mag.com/downloads/2002-03/scmpl.vim > > Ron Cool. Thanks. Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2002-03-03 16:40:41
|
Brian Ingerson [mailto:in...@tt...] wrote: > I'm not sold on the business of interoperability. (Please > sell me). It seems > to me that YAML documents fall within certain domains. I > don't see why my > config file needs to be interoperable with your document processor. The principle is simple. If you have a valid YAML file, I should be able to feed it into my YAML gizmo, no ifs or buts, no special parser flags, no tweaking. It should just work (barring schema issues). That's a major goal IMVHO, and critically important for YAML's acceptance. > I guess the catch 22 situation is that the most common domain > for humans editing YAML is in "config" files. That's exactly > where you would like to avoid having a #TAB directive. (or a > header at all) Right... Tough. So don't use 4-space tabs, then :-) > Here's a common situation where TASTY editors bite you. > Suppose you type the > following by hand: > > --- > comment: some TASTY embedded YAML :) > yaml: | > --- > foo: > - bar > - baz > ... > > You end up with "ambiguous tab converted to spaces" warning > messages because the TASTY editor puts tabs in the last two > lines. I suppose that's not so bad. First, a TASTY editor wouldn't use tabs on output (it would treat them right on input, though). Even if it did put them in the file, the tab is equal to 8 spaces - that's the YAML default. So it just works, no warning. So, if everyone used TASTY editors, our current spec is perfect. No need for any change whatsoever. It is the non TASTY editors which cause trouble, and only them. > All in all, I'll have to agree with Oren's summary above. > Keeping things asis > will get us the farthest, IMO. Adding a #TAB sucks, but then > again, so does > the concept of 4 (or even 6) space TABs. Let 'em get what > they deserve :) The main problem I see is Visual Studio. It *can* be TASTY, it just isn't set up this way out of the box (it uses 4 space tabs by default - shame on them). The problem is that the Visual Studio community isn't known for... well... *sophistication* in such areas. So we have a problem. #TAB could save our hides there... but I agree that we should wait and see whether we actually need it. > --- > > I'm going to start writing a YAML mode for vim that does > auto-indenting with > spaces. Nice. I was toying with the idea of writing one but I've never done a vim syntax mode before, I understand it has quite a learning curve (more like a learning wall). > I'm starting to use YAML as code in Perl. Since Perl allows > data to easily be > used as code, YAML is the perfect way to organize repetitive > or cumbersome > parts of my scripts. I envision that Perl and Python may one day have > language level support for YAML. YAML fits perfectly with Python here... the indentation rules being identical, it would rock. It wouldn't be half-bad on Perl, either. > Since vim's Perl mode is TASTY, I'm wondering if vim can support > multiple syntaxes within a file. I've heard that emacs can. AFAIK it can but it is a hassle - I vaguely remember you have to do some explicit coding in the syntax definition for it. But as I said I don't really know how it works... Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-03-04 12:26:16
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | Goal 1: Any YAML document should work in any YAML system, > | without having to add all sorts of external parser flags. > > I'd like to make mixing tabs and spaces an error This satisfies the goal. > but perhaps > make a few tools available to "fix" the mixing problem. This > tool can then be explicitly invoked. That is, "expand"? That's already available... Putting it into the YAML libraries "as an option" blurs the distinction between what's YAML and what isn't. I want to *know* that I can parse <anything>.yaml! > | Goal 2: YAML's default tab interpretation should be the > | most widely used one. > > I don't think that this need be a goal, since if you > don't mix tabs and spaces you don't have to have an > interpretation of tabs AS spaces. Agreed. I guess I should have qualified the above "if it is necessary to interpret tabs in the first place". That's what the "Therefore" says anyway... > | Goal 3.1: Using any editor in its default setting should > | cope with any YAML. > | > | Therefore: We should not allow mixing spaces and tabs. > > I've yet to meet an editor that forces you to > use both tabs and spaces... > > Show me an editor that forces you to use tabs _and_ spaces. I just > see all of this as unnecessary complexity. Force you, no; but invisibly and sneakingly add tabs without your knowledge, certainly. VI's auto-indent mode for example: - Start VI without any configuration options. - Do "set ai" - auto indent - something anyone editing YAML is guaranteed to set (most people have it set by default in their configuration file anyway). - Indent a line using 8 space characters. - Add an empty line following it using 'O' (the most common way). - Surprise, VI has indented it using a single tab character. You haven't laid a finger on the tab key. You haven't used the '>>' indent line command. You *still* silently and invisibly got space/tab mixtures. I'm certain other editors have their own quirks. Disallowing mixing of spaces and tabs achieves goal 3.1 but throws goal 3.2 out the window. It doesn't even satisfy the weaker form "allow trivial editing using *some* settings". Imagine the horror if you copy from a tab-using document and paste into a space-using document, regardless of editor and settings. The result *looks* OK, but it just doesn't work. I sure don't want to explain *that* in a YAML FAQ... Disallowing mixing is just more trouble than it is worth. Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-03-04 13:33:45
|
On 04/03/02 07:26 -0500, Oren Ben-Kiki wrote: > > Disallowing mixing is just more trouble than it is worth. +1 Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-03-04 22:27:57
|
| We *do* warn when we convert tabs that come before a block scalar line | that has leading whitespace, and the tab crosses the border. This | situation can be quite common when embedding YAML blocks within YAML. Right. | Proposal: | 1) Allow mixing tabs and spaces (as current). | 2) Don't allow mixing for blocks (and folded). Ok. For starters, how about this rule: Tabs are replaced with exactly 8 spaces and after replacement, the column must be evenly divisible by 8. Clark |
From: Brian I. <in...@tt...> - 2002-03-04 23:15:51
|
On 04/03/02 17:28 -0500, Clark C . Evans wrote: > | We *do* warn when we convert tabs that come before a block scalar line > | that has leading whitespace, and the tab crosses the border. This > | situation can be quite common when embedding YAML blocks within YAML. > > Right. > > | Proposal: > | 1) Allow mixing tabs and spaces (as current). > | 2) Don't allow mixing for blocks (and folded). > > Ok. For starters, how about this rule: > > Tabs are replaced with exactly 8 spaces and after > replacement, the column must be evenly divisible by 8. Huh? Does that even make sense? Are you talking about block context only? I'm not really following you here. Give me some examples. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-03-05 01:24:56
|
| > Tabs are replaced with exactly 8 spaces and after | > replacement, the column must be evenly divisible by 8. | | Huh? Does that even make sense? Are you talking about block context | only? I'm not really following you here. There are a few ways in which tabs and space mixing is interpreted: 0. The authoring program treats a tab as equivalent to N spaces necessary to move the column to a multiple of 8. 1a. The authoring program treats a tab as exactly 8 spaces regardless of column. 1b. The authoring program treats a tab as exactly 4 spaces regardless of column (or 3 spaces) I was proposing the following treatment: Yaml treats a tab as exactly 8 spaces; but restricts the expansions to columns evenly divisible by 8, such as column 0, 7, 15, and so on. With this treatment, a YAML file from an editor with tab/space mixing policy 0 works in most cases. In some cases it will error, but those cases occur when spaces could be removed, for example, something like "....\t" that is replaceable by just a tab. Files edited with policy 1a also work in most cases. When a tab is used in columns 0, 7, 15, etc., everything is great. Only in the cases where someone indents 4 and presses the tab key will it reject this file. Files edited with policy 1b will almost always fail since a tab is almost certain to start in column 3 or 4. In those cases where it does work, the YAML indentation will be only one deep; and this may be ok most of the time anyway. Admittedly, there are probably cases which will give bad data here, but they should be rare enough. Thus, by having a hybrid policy between 0 and 1a, common usage of both 0 and 1a work as expected and where it is invalid YAML, we can easily argue that the author is mis-using tab/space mixing. Further, in this case 1b is almost always rejected... good enough. Does this help explain better? Clark |
From: Brian I. <in...@tt...> - 2002-03-05 02:23:40
|
On 04/03/02 20:25 -0500, Clark C . Evans wrote: > | > Tabs are replaced with exactly 8 spaces and after > | > replacement, the column must be evenly divisible by 8. > | > | Huh? Does that even make sense? Are you talking about block context > | only? I'm not really following you here. > > There are a few ways in which tabs and space mixing > is interpreted: > > 0. The authoring program treats a tab as equivalent > to N spaces necessary to move the column to a > multiple of 8. > > 1a. The authoring program treats a tab as exactly 8 spaces > regardless of column. > > 1b. The authoring program treats a tab as exactly 4 spaces > regardless of column (or 3 spaces) I have not really seen behaviour 1a. or 1b for that matter. > > I was proposing the following treatment: > > Yaml treats a tab as exactly 8 spaces; but restricts > the expansions to columns evenly divisible by 8, such > as column 0, 7, 15, and so on. How are 7 & 15 divisible by 8? Maybe if you made the first column -1. > > With this treatment, a YAML file from an editor with tab/space > mixing policy 0 works in most cases. In some cases it will error, > but those cases occur when spaces could be removed, for example, > something like "....\t" that is replaceable by just a tab. > > Files edited with policy 1a also work in most cases. When a tab > is used in columns 0, 7, 15, etc., everything is great. Only in > the cases where someone indents 4 and presses the tab key will > it reject this file. > > Files edited with policy 1b will almost always fail since a tab > is almost certain to start in column 3 or 4. In those cases where > it does work, the YAML indentation will be only one deep; and this > may be ok most of the time anyway. Admittedly, there are probably > cases which will give bad data here, but they should be rare enough. > > Thus, by having a hybrid policy between 0 and 1a, common usage of > both 0 and 1a work as expected and where it is invalid YAML, we can > easily argue that the author is mis-using tab/space mixing. Further, > in this case 1b is almost always rejected... good enough. > > Does this help explain better? Seems very odd to me. Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2002-03-05 07:09:47
|
Brian Ingerson [mailto:in...@tt...] wrote: > > Does this help explain better? > > Seems very odd to me. +1. There's already wording to the effect that emitters "should not" emit redundant spaces. I think that's enough. The goal is not to make miserable the average Joe hitting the tab key to get to the next indentation position... let's just keep things as they are for now. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-03-05 13:23:53
|
On Tue, Mar 05, 2002 at 02:09:25AM -0500, Oren Ben-Kiki wrote: | Brian Ingerson [mailto:in...@tt...] wrote: | > > Does this help explain better? | > | > Seems very odd to me. | | +1. There's already wording to the effect that emitters "should not" emit | redundant spaces. I think that's enough. The goal is not to make miserable | the average Joe hitting the tab key to get to the next indentation | position... let's just keep things as they are for now. Ok. I guess this is ok, my proposal didn't solve the problem anyway (it was only a partial solution) and Brian was right, I meant 0,8,16, etc. *blush* As I see it, the problem is that different editors have different tab/space mixing policy. In particular, VisualStudio treats a tab as 4 spaces by default. Thus, a file edited by VisualStudio may look good and be valid YAML, but what the author sees isn't what YAML sees. For instance, assume the following where the period (.) is a space and the exclamation (!) is a tab. --- parent: ....child: !another: ] !....value # # In VisualStudio, you would see --- parent: child: another: ] value # # While YAML/vi sees... --- parent: child: another: ] value # Any good solutions? I guess there isn't any other than issuing a warning that tabs and spaces were mixed. Clark |
From: Clark C . E. <cc...@cl...> - 2002-03-05 13:49:08
|
| --- | parent: | ....child: | !another: ] | !....value | # | # In VisualStudio, you would see | --- | parent: | child: | another: ] | value | # | # While YAML/vi sees... | --- | parent: | child: | another: ] | value 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 VisualStudio will see/use valid YAML files which mix spaces and tabs incorrectly. 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 VisualStudio 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. 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. 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). 4. Like #3, only use a command-line argument. Good: Allows different people to use differnet styles Bad: People bake-in the command-line arguments and thus this case is no better than 0 or 3. In short, I think the current state 0, is not good and I think that option 1 (reject YAML with mixed tabs/spaces) is the only really good solution. Best, Clark | # | | Any good solutions? I guess there isn't any other than | issuing a warning that tabs and spaces were mixed. | | 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-05 14:44:59
|
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 |
From: Clark C . E. <cc...@cl...> - 2002-03-05 16:04:28
|
| > Options: | > | > 0. Don't worry about it, don't issue warnings and | > use the vi view. | | Also, the most likely result would be that their YAML file won't | parse, with error messages about bad indentation levels. Most likely they won't be error messages about bad indentation, but will be the *wrong* indentation and hence the wrong data -- I'm concerned that people looking at YAML using these editors will see the wrong structure. This could give YAML a bad rap... like "make". If we went this route (status quo) then I suggest that we add the restriction that tabs can only occur at columns evenly divisible by 8 (0,8,16,). This will improve the chances of a file being more readable in a non-TASTY editor and will make an syntax error more likely in those cases where a structural error has occurred. Unfortunately this restriction doesn't solve the problem. | > 1. Throw an error when tabs and spaces are mixed, | > provide a third party utility to "fix" invalid | > YAML such as the example above. | | In short, this has the advantage of pissing off almost everyone :-) Yes, but we show our laundry up front and editors can develop smart modes which don't mix tabs and spaces. At least in this case there is no possibility for a valid YAML file to be interpreted incorrectly. IMHO, this is most important. Perhaps the best option is to just forbid tab indentation, and to provide a utility to "expand" the tabs. In other words, since we can't do tabs in such a way that they are correct everwhere, we don't do it at all. This at least saves your cut'n'paste use case. | > 3. Have a #TAB directive explaining the policy and | > allow a fixed set of policies. | | 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?). I can say the same for #1 here. They will only get bitten once. Ohh, I can't mix tabs and spaces, OK. Notepad doesn't force you to use tabs. I'm starting to like the option of going back to removing TAB usage alltogether. | > In short, I think the current state 0, is not good | | Agreed. | | > 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. No it doesn't, just don't use tabs. | 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. The primary problem with this is that once you allow this sort of freedom you can't go back easily. | 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? My python experience is what motivated the additional TAB restriction to stop people from doing "^....\t" when they could just as easily do "^\t". Those extra non-significant spaces cause all kinds of grief. Most Visual Studio shops arn't Unix shops and vice versa, so in practice there isn't much of a problem. The only problem occurs when you try to share stuff between the shops... which is rare for source code. Also Visual Studio shops tend to be VB not Python. Best, Clark |