From: Clark C . E. <cc...@cl...> - 2002-03-06 14:36:53
|
Oren, Thanks for the summary. Here is the summary in a grid. Option | Cut&Paste | View | Edit | Parse --------------+-----------+------+------+-------- 8-space tabs | 3 | 1+ | 1 | 3 Mixing forbid | 1 | 3 | 0 | 3 Mixing warn | 1 | 2 | 1 | 3 #TAB | 2 | 2- | 2 | 3 CLI Option | 2 | 1 | 1 | 0 No Tabs | 3 | 3 | 0 | 3 | The situation is basically unchanged. Options 0, 3 and 5 are | still roughly equal. I still believe the clinching argument | is that option 4 leads to option 4 which is the worst possible | one, while option 0 leads to option 3 which is one of the | least-bad ones. We can move from: No Tabs -> 8-space Tabs -> (#TAB | Mixing warn/forbid) So, the most restrictive is to just ban tabs, and given the chart above, it's probably easier to configure editors to not use tabs (and to be explicit about the problems with tabs). | I'm starting to wonder whether we shouldn't just move to option 3 and be | done (that is, adopt YAC#21). It is the most balanced one (in addressing the | different concerns). It is also the one which dictates least to people. All | other options (except 4 which is horrid) try to dictate one way to handle an | issue for which there simply is no single good solution. I think #TAB is overkill, and that the #TAB meta-data is bound to get out-of-sync with the actual data causing all kinds of hard-to-find problems. Icky. Better have the parser toss up its arms when it encounters a TAB and provide a few utilities to help "fix" YAML data that comes from editors that use tabs. Best, Clark |