Assorted haml parsing errors

[Topher Hunt]

Howdy! I'm a haml fan, and I've continued to use phoenix_haml in my apps despite knowing that the generators are way out-of-date. But lately I've run into lots of parsing errors when parsing basic haml syntax, with increasing frequency, and it's lead me to treat Phoenix haml support as thoroughly broken.

I'm raising this issue not to get all these specific bugs fixed, but rather to document them for visibility and to raise the question: Is this project alive? Is there an active commitment to supporting haml markup in modern Phoenix apps?

Now that I've realized how many gotchas & bugs I'm dealing with, I've dropped back to plain eex and found the transition easier than expected. Maybe eex fits better with the Elixir community's tendency to eschew unnecessary layers of complexity, and I'd be open to hearing a response of "Yeah haml is no longer a priority for us". But it feels important to ask the question, and if this is the answer, I'd love to ensure the readme reflects that.

Some examples of haml parsing errors that gave me headaches recently:
(for reference, my mix.lock has phoenix_haml 0.2.3 and calliope 0.4.1.)

# Naming this form parameter `_f` produces a parsing error. Instead I need to
# name the var `f` (no leading underscore), which produces Elixir unused var warnings.
- form_for @changeset, create_or_update_path(@conn, @changeset), fn(_f) -> 
# => parsing error

# Similarly, params in a mapping function can't contain an underscore.
# 
# This works:
- Enum.map tag_list(video), fn(tag) ->
  blah
#
# But this produces a parsing error:
- Enum.map tag_list(video), fn(tag_text) ->
  blah

# Multiple injects in same line cause leading text to be swallowed:
%p Apple #{"bear"} cat #{"dog"} elephant #{"fig"}
# => <p>elephant fig</p>

# Parens in text (which I intended as literal) cause leading text to be swallowed:
%p Apple (bear) cat
# => <p>cat</p>

# Quoted element attributes sometimes result in a parsing error, sometimes are rendered 
# with literal quotes (which probably isn't what the dev wanted).
# It's easy to accidentally wrap your data attrs in quotes when you're switching between 
# haml syntax and Elixir expressions like `link` calls.
#
# e.g. This example renders a parsing error as I'd expect & want:
.some-div{"data-one": "abc", "data-two": "def"} Content
#
# But this renders a div with a `data-one` attr and an (invalid AFAIK, and unintended) 
# `"data-two"` attr:
.some-div{data-one: "abc", "data-two": "def"} Content

# A bare `%` is rendered as `<>` and can have content nested under it. 
# I'd expect it to produce  a parsing error. E.g.:
%
  Something
# => "<> Something"