HAML parser overlooking #{xxx} ?

I'm liking this HAML stuff and the editing tools are a lot of the reason. So a detail which seems like a bug:

The analysis of HAML code is apparently not looking at embedded Ruby inside #{} constructs. This shows up
in two ways, Variables defined outside of #{} and used only within #{} are flagged as unused. Maybe
that's confusing, here's an example (build #1421)
HAML-issue.jpg
Here, div_is has been incorrectly flagged as unused; if I reference it in an '= code' construct it would not be flagged.

Another way I see this is that undefined variables are not flagged inside #{}. So
= i.is.undefined
is flagged (the i is correctly marked), but
#{i.is.undefined} in the same context is not marked.

Did I miss this in the issue list?

Cheers,
Gordon

2 comments
Comment actions Permalink

Hi Gordon,

gjf wrote:

I'm liking this HAML stuff and the editing tools are a lot of the reason. So a detail which seems like a bug:

The analysis of HAML code is apparently not looking at embedded Ruby inside #{} constructs. This shows up
in two ways, Variables defined outside of #{} and used only within #{} are flagged as unused. Maybe
that's confusing, here's an example (build #1421)
HAML-issue.jpg
Here, div_is has been incorrectly flagged as unused; if I reference it in an '= code' construct it would not be flagged.

Another way I see this is that undefined variables are not flagged inside #{}. So
= i.is.undefined
is flagged (the i is correctly marked), but
#{i.is.undefined} in the same context is not marked.

Did I miss this in the issue list?

Cheers,
Gordon

As you can see in statement %div(id="#{div_id}") - div_id is not treated as ruby code, this stuff isn't supported yet.
I've created an issue in YouTrack at: http://www.jetbrains.net/tracker/issue/RUBY-5031
As always, feel free to vote, comment and track progress.

Regards,
Oleg

0
Comment actions Permalink

I've just fixed this, thanks again for the issue!

Regards,
Oleg

0

Please sign in to leave a comment.