From: Oren Ben-K. <or...@ri...> - 2002-02-26 10:13:34
|
We have discussed #TAB in passing at the time, then abandoned it when we decided to use one-space indentation. Now that tabs are valid indentation characters again, I think we should spend a bit of thought whether a #TAB makes sense or not. So, to get things rolling, here's YAC#21. I'm not certain how I'm voting on this yet... The premise is that a #TAB:N directive would make YAML easier to work with for most people. Thoughts? Have fun, Oren Ben-Kiki # YAC 21 --- location: http://www.yaml.org/yacs/021 abstract: Supporting different sized tabs owner: oren status: !yac/status state: new date: 2002-02-11 proposal: ] Add a #TAB:N directive which specifies the size of tab characters. The default would be 8, as today. rationale: ] Some people have editing systems which make it difficult to use 8-space tabs. This is especially relevant to non power users. As things are today, people using 4-space tabs would find they mostly work - as long as they don't mix spaces and tabs. When these mix, the document would no longer parse correctly. By adding the #TAB directive it would be possible for such people to safely use their editor in its default setting. This should reduce the entry barrier for manually editing YAML files. Only when such people attempt to edit a YAML file created elsewhere with a different tab size they would have a problem. It is expected that this case would be much rarer than editing a locally-created file. Files can be easily fixed for local editing by running them through 'expand', and perhaps we should provide a YAML-aware expand program (pretty trivial to write) to allow people to handle foreign files. It is assumed that people would be more willing to run foreign files through a filter for editing than tweak the tab setting in their editor (again, this focuses on non-power users). examples: | --- #TAB:4 # Document uses 4-space tabs. --- # Document uses 8-space tabs. --- |
From: Steve H. <sh...@zi...> - 2002-02-26 11:58:26
|
> We have discussed #TAB in passing at the time, then abandoned it when we > decided to use one-space indentation. Now that tabs are valid indentation > characters again, I think we should spend a bit of thought whether a #TAB > makes sense or not. So, to get things rolling, here's YAC#21. > 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. Even though YAML has a default setting of of 8 spaces, I think we should require the #TAB directive in any file that has tabs. If we discourage folks from using tabs, then it makes it marginally easier to write one-off tools that look for stuff in YAML files without actually parsing it. Also, if folks want to make round-tripping YAML tools, then they can just save the indent levels of branches, not leafs. |
From: Stephane P. <s.p...@wa...> - 2002-03-03 08:35:19
|
On Tue, 26 Feb 2002, Steve Howell wrote: > > We have discussed #TAB in passing at the time, then abandoned it when we > > decided to use one-space indentation. Now that tabs are valid indentati= on > > characters again, I think we should spend a bit of thought whether a #T= AB > > makes sense or not. So, to get things rolling, here's YAC#21. > > >=20 > I will give the tab-hater's view. Spacers are unambiguous, so they are a= lways > better for the reader than the tabs. I always set my editor to save spac= es. > 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. >=20 > Even though YAML has a default setting of of 8 spaces, I think we should = require > the #TAB directive in any file that has tabs. >=20 > If we discourage folks from using tabs, then it makes it marginally easie= r to > write one-off tools that look for stuff in YAML files without actually pa= rsing > it. Also, if folks want to make round-tripping YAML tools, then they can= just > save the indent levels of branches, not leafs. The tabulation was a user-settable mechanical device. It can be emulated wi= th spaces. Thas saves from endless complications. I agree we should discourage people = to use it or even forbid it altogether.=20 I am sorry to not follow things closely and to give so late a feedback. --=20 St=E9phane Payrard -- s.payrard@@wanadoo.fr # mailstat Most people don't type their own logfiles; but, what do I care? |
From: Brian I. <in...@tt...> - 2002-03-01 06:08:30
|
On 26/02/02 05:13 -0500, Oren Ben-Kiki wrote: > We have discussed #TAB in passing at the time, then abandoned it when we > decided to use one-space indentation. Now that tabs are valid indentation > characters again, I think we should spend a bit of thought whether a #TAB > makes sense or not. So, to get things rolling, here's YAC#21. > > I'm not certain how I'm voting on this yet... The premise is that a #TAB:N > directive would make YAML easier to work with for most people. Thoughts? Sorry to get in late on this thread. (But sometimes that's the best way. Let everyone else do the fighting ;) 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. I'll also say that I am very comfortable with the current whitespace rules; at least for trying them out over the next 3-6 months. They are the result of *much* thought by all of us. FWIW, it basically comes down to this: TABs are tricky and we've never liked them, but we've conceded that many editors will silently insert them, and we don't want to punish the users for something they can't see. 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. Cheers, Brian |