The problem is not so much that the specific indentation has been hard-coded (it has in a few places for reasons of simplicity, but not enough that they would be terribly difficult to change). The bigger problem is that there are numerous places where indentation is important for more than generation: re-indenting code that's already indented, for instance. This is the stuff that would be difficult to track down and get exactly right, especially with an arbitrary string as indentation.
On Fri, Feb 26, 2010 at 1:14 AM, dreamcat four <[email protected]> wrote: > On Fri, Feb 26, 2010 at 7:18 AM, Nathan Weizenbaum <[email protected]> > wrote: > > Changing the output indentation would require a reasonably large amount > of > > code and modification to the Haml renderer. It would certainly be doable, > > Ah :) > > I was nearly going to ask "if it would take a lot more effort", but I > kindda couldn't believe that the indentation style / amount would be > hardcoded in-place. Maybe that brings some kind of performance > advantage. > > > If you really want this, I'll accept a patch. However, I think the patch > > would be reasonably in-depth, and I don't really want to spend the time > > writing or re-writing large chunks of it, so read the submission > guidelines > > carefully and be prepared for a stringent code review if you do send one > in. > > Okay, message 'recieved. But it sounds to me like this 2 spaces indent > has been hard-coded around the houses everywhere. Therefore perhaps > also more tempting for me also just to stay away from it too. We'll > have to see. > > > Even if we do add an option for adjustable output indentation, I would > want > > it to be entirely independent of input indentation. Inferring it from the > > input is too big of a backwards-incompatibility, and too much > > behind-the-scenes decision-making. > > I was originally hoping to default the output indent from the input > indent, which is already inferred / detected by the existing code as > engine.indent(). Maybe that isnt what you're talking about here. There > would be 1 new user-settable option. To override the output indent (of > a loading/ed engine) with an arbitrary string, which represent 1 level > of indent. > > Again, I originally thought this would be easy because it only makes > the assumption that we can emit (output) each indent as a discrete > string, and hardcocded in only one place was the original 2 space > indent amount which we want to be replacing by. So if the custom > indent option were set, it wouldn't be related to or inferred from the > input indent. > > Correct / incorrect ? > > >> > >> > >> dreamcat4 > >> [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] <haml%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/haml?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
