Skip to content
Commits on May 11, 2012
  1. @norman

    Updated Changelog


    norman committed May 11, 2012
  2. @norman

    Don't adjust whitespace if buffer has preserve tag

    This is in references to various issues on Github, including:
    Issue #532, #519, #516, #506, and #503.
    Recently I released 3.1.5 to work around a change in Rails 3.2.3 which
    made textarea helpers append newlines to the opening tag. Rails's
    motivation for this change was to fix a longstanding bug which impeded
    the ability to save texarea content with leading newlines.
    Unfortunately, Haml 3.1.4 treated this newline as content, rather than
    as a seperator between the textarea tag and its content.
    Solving the issue was not simply a matter of decoding the newline,
    because in indented mode, Haml would add spaces before the newline in
    partials, making nested textareas have spaces before their content.
    Haml 3.1.5 solved this by adding <haml:newline/> rather than a newline,
    and monkeypatched Rails to replace it with a real newline after the
    document was rendered. You ever do something you just *know* is going to
    cause problems, even though all your tests seem to indicate things are
    working fine? Yeah, I know that feeling.
    As it turns out, monkeypatching the Rails does the actual
    rendering is not as easy as it seems. First, because there are several
    places where a monkey patch needs to be applied. Second, because those
    modules are not always loaded, and it's not very nice to force people to
    load them in order to use Haml: an application may have a very good
    reason not to have loaded part of Rails.
    Last but not least, the monkeypatch caused <haml:newline/> to appear in
    some Erb documents when the haml gem was loaded for use elsewhere in the
    This commit attempts to make a simpler and wiser solution to the issue.
    Rather than adding some silly tag (WTF was I thinking???), this simple
    makes Haml replace the first encoded newline emitted by Rails's textarea
    helper methods with a real newline. Then, when rending the Haml
    document in ugly mode, everything works exactly as you would expect,
    with no need to monkepatch Rails's template rendering.
    However this comes with a tradeoff: in order to not completely break
    textareas in indented mode, Haml will now make no attempt to reindent a
    partials or the output of helpers when they match a very simple regular
    expression for opening <textarea>, <pre>, or <code> tags.
    This makes textareas work properly in Haml 3.1.6. at the expense of
    slightly uglier documents, when those documents contain the listed tags.
    Now, everybody knows that you shouldn't rely on regular expressions to
    parse HTML. This is where another tradeoff comes in: parsing the buffer
    with an XML parser would have a much larger impact on performance, and
    Haml is already slow enough as it stands in indented mode. So I've
    compromised and used a simple, somewhat braindead, but fast regexp.
    This issue has been nagging and annoying, and I apologize to anybody
    affected by this, most especially for the <haml:newline/> silliness in
    introduced in 3.1.5. Please give Haml 3.1.6 a try (it's currently in the
    stable branch) and let me know if you come across any problems. I'll try
    to get this release out as soon as possible.
    The change is also in the master branch, for those who like to live
    norman committed May 11, 2012
Commits on May 7, 2012
  1. @norman

    Added note about testing on 1.8 and 1.9.

    [ci skip]
    norman committed May 7, 2012
  2. @norman
  3. @norman
  4. @norman
  5. @norman
Commits on May 6, 2012
  1. @mattwildig

    Undef method before replacing it.

    In order to suppress warnings.
    mattwildig committed May 6, 2012
  2. @mattwildig

    Remove unused variable.

    mattwildig committed May 6, 2012
  3. @mattwildig
  4. @mattwildig
Commits on May 5, 2012
  1. @cristianrasch
  2. @cristianrasch
  3. @norman

    Revert "[Haml] Refactored some more code to reduce the number of warn…

    …ings in the test suite"
    This reverts commit fef4a39.
    norman committed May 5, 2012
  4. @norman
  5. Merge pull request #525 from joliss/travis

    Re-add rbx-18mode and rbx-19mode, but ignore failures
    Norman Clarke committed May 5, 2012
  6. @joliss
Commits on May 4, 2012
  1. [Haml] Refactored some more code to reduce the number of warnings in …

    …the test suite
    Cristian Rasch committed May 4, 2012
  2. Merge remote-tracking branch 'upstream/master'

    Cristian Rasch committed May 4, 2012
  3. Merge pull request #521 from joliss/badges

    Add Travis badge
    Norman Clarke committed May 4, 2012
  4. @joliss

    Add Travis badge

    joliss committed May 4, 2012
Commits on May 1, 2012
  1. @norman

    Commented out RBX... again.

    Damnit. I really want to run CI on RBX. All tests pass for me locally
    with 1.4.2 and 2.0.0-dev on rbenv, but on Travis they fail. I just tried
    installing RVM again to use *exactly* what Travis is using, but at this
    point I feel like I'm just gaming the system to make the tests pass
    rather than focusing on real progress. I guess I'll just wait until 2.0
    is released, testing against RBX on Travis right now is just too
    norman committed May 1, 2012
  2. @norman

    Test with rbx on Travis again

    norman committed May 1, 2012
  3. @norman

    Fix for rbx

    norman committed May 1, 2012
  4. @norman

    Account for rbx error messages

    norman committed May 1, 2012
  5. @norman

    Account for rbx backtraces

    norman committed May 1, 2012
  6. @norman
  7. @norman
  8. @norman
  9. @norman

    Fix test for rbx

    norman committed May 1, 2012
  10. @norman
  11. @norman

    Merge branch 'stable'

    norman committed May 1, 2012
  12. @norman

    Moved site to

    norman committed May 1, 2012
  13. @norman

    Bump from beta to rc

    norman committed May 1, 2012
Commits on Apr 30, 2012
  1. @norman

    Merge branch '315' into stable

    norman committed Apr 30, 2012
Something went wrong with that request. Please try again.