From: Oren Ben-K. <or...@ri...> - 2001-12-24 19:13:59
|
Brian Ingerson [mailto:in...@tt...] wrote: > Proposal: \ > An INDENT directive should be added to allow indentation widths other > than one space. For example, INDENT:8 would mean 8 space indent. > Rationale: \ > After converting the httpd.conf file to YAML it became > apparent that it > is easy to get lost in single space indentation. Especially in the > presence of many comment lines. > Notes: > - Single space will remain the default. > - This proposal does *not* allow for TABs in indentation. > ... I guess that non-1-space indentation would be something we'll just have to handle eventually. I'd like to revisit the reason we can't do generic (Python-like) indent. The reason is multi-line folded scalars: this case: | <indent> <-leading space Alternative we discussed was to specify the indentation somehow: by number: \4 indented 4 spaces default: \ next line can't have leading spaces. further lines can. If we accepted this the problem would be dead forever. Anyone would be able to use what he wants, period. It would also make YAX#6.2 almost not a special case, and allow other formatting improvements (see below). Speaking of YAC#6.2, it only makes sense if we have fixed 1-space indentation, OR some generic indentation scheme. It makes no sense at all to double-indent for fixed 4-space indentation. So if we go for any scheme that used a *fixed* non-1-space indentation, YAC#6.2 goes out the door. As far as whether 1 space indentation works... I wrote a Makefile generator for my Java project, using Makefile.yaml as input and using Brian's yaml-0.23 (thanks Brian! it works nicely for me!). I found out that one space indentation isn't enough to latch on to, visually. I also found out it looks much better to write: this: - entry - entry than that: - entry - entry This can be done in any fixed indentation scheme (making the indent for the '-' be 0). In a generic indentation scheme it means the minimal indentation for '-' is zero rather than 1. BTW, this got me thinking that in a generic indentation scheme we should specify the productions with 'n' being not the indent level, but the actual number of spaces to indent. This way one could easily say thing(n) ::= ( indent(n) something(n+k) line_break )* Also: simple(n) ::= <indicator> <k>? line_break <simple_line>(n+<k>)* This way the fact the same indent level is used for all entries in a branch is explicit in the BNF, and it is easy to specify how it is explicitly given for leaf formats... It all works so nicely together. Summary: I think we should go for broke and allow generic indentation rather than use an INDENT directive. I think the *minimal* indentation for the '-' for a series should be zero. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-12-25 04:21:08
|
Brian Ingerson [mailto:in...@tt...] wrote: > > this case: | > > <indent> <-leading space > > Right. > > > Alternative we discussed was to specify the indentation somehow: > > > > by number: \4 > > indented 4 spaces > > default: \ > > next line can't have leading spaces. > > further lines can. > > > > If we accepted this the problem would be dead forever. > > Anyone would be able > > to use what he wants, period. > > Cool. > > But I think we can do better than that for syntax. > Let's see... Let's. > Well, we need at least one space of indentation for > multi-lines... Hmmm. If we do that the problem is solved, I guess... But I find it to be too restrictive. It doesn't look all that great... > Another option is to use a visual indicator. > - | > >Two space indenting > - \\ > One space indent is the default. This one's a YUCK, not a YAC :-) I have the same objection to both: they makes everything ugly, noy just the cases where there are leading spaces. My proposal above (a rehash of old proposals we had) works great as long as there are no leading spaces. It only looks strange if you have them - which is a pretty rare case. > > Speaking of YAC#6.2, it only makes sense if we have fixed 1-space > > indentation, OR some generic indentation scheme. It makes > > no sense at all to > > double-indent for fixed 4-space indentation. So if we go > > for any scheme that > > used a *fixed* non-1-space indentation, YAC#6.2 goes out the door. > > I realized this. I think it's one of the reasons that 6.2 is a hack. I > haven't been that in favor of it. I guess flexible > indentation could make it > reasonable though. Quite. > > this: > > - entry > > - entry > > than that: > > - entry > > - entry > ... > # so is this: > --- > - > - > - > - foo > # this: > --- > - > - > - > - foo > # or this: > - '' > - '' > - '' > - foo > ... Ouch. Point made. Forget about it, then. > > Summary: I think we should go for broke and allow generic > indentation rather > > than use an INDENT directive. > > Yes. Would \<k> work for you? And what's Clark's view on all this? > > I think the *minimal* indentation for the '-' > > for a series should be zero. > > No. Agreed. Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-12-25 05:10:16
|
On 25/12/01 06:21 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > > this case: | > > > <indent> <-leading space > > > > Right. > > > > > Alternative we discussed was to specify the indentation somehow: > > > > > > by number: \4 > > > indented 4 spaces > > > default: \ > > > next line can't have leading spaces. > > > further lines can. > > > > > > If we accepted this the problem would be dead forever. > > > Anyone would be able > > > to use what he wants, period. > > > > Cool. > > > > But I think we can do better than that for syntax. > > Let's see... > > Let's. > > > Well, we need at least one space of indentation for > > multi-lines... > > Hmmm. If we do that the problem is solved, I guess... But I find it to be > too restrictive. It doesn't look all that great... OK. But single space *will* be the canonical form, right? And single space will require no additional syntax, right? Okay by me. We can add some extra syntax for varying indentation, but I doubt there'll be much call for it. > > > Another option is to use a visual indicator. > > - | > > >Two space indenting > > - \\ > > One space indent is the default. > > This one's a YUCK, not a YAC :-) I have the same objection to both: they > makes everything ugly, noy just the cases where there are leading spaces. My > proposal above (a rehash of old proposals we had) works great as long as > there are no leading spaces. It only looks strange if you have them - which > is a pretty rare case. Yeah. After thinking more about this, I agree that the indication should go above; separate from the content. I'm just not sure that I like \<k>. > > > > Speaking of YAC#6.2, it only makes sense if we have fixed 1-space > > > indentation, OR some generic indentation scheme. It makes > > > no sense at all to > > > double-indent for fixed 4-space indentation. So if we go > > > for any scheme that > > > used a *fixed* non-1-space indentation, YAC#6.2 goes out the door. > > > > I realized this. I think it's one of the reasons that 6.2 is a hack. I > > haven't been that in favor of it. I guess flexible > > indentation could make it > > reasonable though. > > Quite. I think we need to solve 6.2 *after* solving indentation. (But let's keep it in mind of course) > > > > this: > > > - entry > > > - entry > > > than that: > > > - entry > > > - entry > > ... > > # so is this: > > --- > > - > > - > > - > > - foo > > # this: > > --- > > - > > - > > - > > - foo > > # or this: > > - '' > > - '' > > - '' > > - foo > > ... > > Ouch. Point made. Forget about it, then. > > > > Summary: I think we should go for broke and allow generic > > indentation rather > > > than use an INDENT directive. > > > > Yes. > > Would \<k> work for you? And what's Clark's view on all this? Actually \<k> *would* work. As in: - \<3> foo bar I think it's better to make the number special somehow. > > > > I think the *minimal* indentation for the '-' > > > for a series should be zero. > > > > No. > > Agreed. > Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2001-12-25 16:18:26
|
Brian Ingerson [mailto:in...@tt...] wrote: > OK. But single space *will* be the canonical form, right? And > single space > will require no additional syntax, right? Okay by me. > > We can add some extra syntax for varying indentation, but I > doubt there'll be > much call for it. One space can be 'canonical' - I'd define 'canonical' to be 'minimal' - the shortest possible serialization (that's nicely unambiguous). As for extra syntax, what I had in mind would not require anything special 99% of the time that one uses *any* indentation. this: is indented 4 spaces. Indentation is simply copied from the first indented line. This works unless this line has leading spaces. 99% of them won't, so no extra syntax is called for and one can simply use whatever indentation he wants. In the 1% (or whatever) of the cases where the first line does contain leading white space, and only in these cases, one would have to write something extra. > Actually \<k> *would* work. As in: > > - \<3> > foo > bar > > I think it's better to make the number special somehow. Makes sense. The above could work... How about: this: \^1 has 3 leading spaces. also allow: \ ^1 has 3 leading spaces Given that ^ serves as a marker for start-of-line in regular expressions? I think it works better. > I think we need to solve 6.2 *after* solving indentation. (But let's > keep it in mind of course) Right. I don't think it would pose any problems though. So, summary of how I'd like to see this YAC: 1. Indentation is taken from first indented line, 2. except for a next-line leaf node with an explicit indentation annotation *after* the next-line indicator, 3. which may be separated from the indicator by optional white space, 4. contains an integer - number of columns the value is indented, 5. in the format ^indentation-level It seems we agree on 1, 2, 4. I don't think you have a problem with 3. As for 5, there are many syntax forms we could use but I rather like ^ - it is consistent with YAML's way of annotating stuff (using a prefix character). Clark is rather silent - I guess he's under water again... I hope it all works out OK for him. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-28 16:45:21
|
| So, summary of how I'd like to see this YAC: | 1. Indentation is taken from first indented line, | 2. except for a next-line leaf node with an explicit indentation annotation | *after* the next-line indicator, | 3. which may be separated from the indicator by optional white space, | 4. contains an integer - number of columns the value is indented, | 5. in the format ^indentation-level How about... Indentation is taken from the first indented line, except in the next-line leaf node case, where an integer is provided immediately after the indicator. In this case, the indentation is provided allowing for leading spaces. for-example: | This does not have any leading spaces. and-this: |2 one has two leading spaces, no? Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Oren Ben-K. <or...@ri...> - 2001-12-29 20:16:14
|
Clark C . Evans wrote: > | So, summary of how I'd like to see this YAC: > | 1. Indentation is taken from first indented line, > | 2. except for a next-line leaf node with an explicit indentation > | annotation *after* the next-line indicator, > | 3. which may be separated from the indicator by optional white space, > | 4. contains an integer - number of columns the value is indented, > | 5. in the format ^indentation-level > > How about... > > Indentation is taken from the first indented line, > except in the next-line leaf node case, where an > integer is provided immediately after the indicator. > In this case, the indentation is provided allowing > for leading spaces. Seems exactly the same thing - except for points #3 and #5. I'll go with your version - it is the minimal one... Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-12-24 23:15:01
|
On 24/12/01 21:14 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > Proposal: \ > > An INDENT directive should be added to allow indentation widths other > > than one space. For example, INDENT:8 would mean 8 space indent. > > Rationale: \ > > After converting the httpd.conf file to YAML it became > > apparent that it > > is easy to get lost in single space indentation. Especially in the > > presence of many comment lines. > > Notes: > > - Single space will remain the default. > > - This proposal does *not* allow for TABs in indentation. > > ... > > I guess that non-1-space indentation would be something we'll just have to > handle eventually. I'd like to revisit the reason we can't do generic > (Python-like) indent. The reason is multi-line folded scalars: > > this case: | > <indent> <-leading space Right. > Alternative we discussed was to specify the indentation somehow: > > by number: \4 > indented 4 spaces > default: \ > next line can't have leading spaces. > further lines can. > > If we accepted this the problem would be dead forever. Anyone would be able > to use what he wants, period. Cool. But I think we can do better than that for syntax. Let's see... Well, we need at least one space of indentation for multi-lines. I think we agree on that. How about we limit indentation of multi-lines to exactly one space? The need for more indentation doesn't really apply that much to multi-lines. Another option is to use a visual indicator. - \ > This is 5 space indenting. - | >Two space indenting - \\ One space indent is the default. This has an edge case, but I'm sure Oren can figure out how to deal with it :) > It would also make YAX#6.2 almost not a > special case, and allow other formatting improvements (see below). > > Speaking of YAC#6.2, it only makes sense if we have fixed 1-space > indentation, OR some generic indentation scheme. It makes no sense at all to > double-indent for fixed 4-space indentation. So if we go for any scheme that > used a *fixed* non-1-space indentation, YAC#6.2 goes out the door. I realized this. I think it's one of the reasons that 6.2 is a hack. I haven't been that in favor of it. I guess flexible indentation could make it reasonable though. > > As far as whether 1 space indentation works... I wrote a Makefile generator > for my Java project, using Makefile.yaml as input and using Brian's > yaml-0.23 (thanks Brian! it works nicely for me!). I found out that one > space indentation isn't enough to latch on to, visually. I also found out it > looks much better to write: > > this: > - entry > - entry > than that: > - entry > - entry > > This can be done in any fixed indentation scheme (making the indent for the > '-' be 0). In a generic indentation scheme it means the minimal indentation > for '-' is zero rather than 1. # so is this: --- - - - - foo # this: --- - - - - foo # or this: - '' - '' - '' - foo ... I think this is not a good idea. Even if you can find the rules to make it work out, it's confusing. > BTW, this got me thinking that in a generic indentation scheme we should > specify the productions with 'n' being not the indent level, but the actual > number of spaces to indent. This way one could easily say > > thing(n) ::= ( indent(n) something(n+k) line_break )* > > Also: > > simple(n) ::= <indicator> <k>? line_break <simple_line>(n+<k>)* > > This way the fact the same indent level is used for all entries in a branch > is explicit in the BNF, and it is easy to specify how it is explicitly given > for leaf formats... It all works so nicely together. > > Summary: I think we should go for broke and allow generic indentation rather > than use an INDENT directive. Yes. > I think the *minimal* indentation for the '-' > for a series should be zero. No. Cheers, Brian |