0x2c7/ruby_jard

[BUG] - No ERB support

scottbarrow opened this issue · 4 comments

Describe the bug
Adding Jard to an erb file does not pause at runtime

To Reproduce
Steps to reproduce the behavior:
1: Add jard to an erb file (Rails)

Expected behavior
Jard to stop execution at the point specified in the erb file

Actual behavior
Jard does not stop execution

0x2c7 commented

Hi @scottbarrow, thanks for your reporting. I have just tested in my local environment (Ruby 2.6.5, and 2.7.1 on Rails 6.0). It works quite well.

Screenshot from 2020-09-14 11-26-42

Could you give me some more information, such as your Ruby version, your Rails version, the environment you are running on (mac, linux?). If it's possible, could you try with a simple view, or empty view?

0x2c7 commented

Ahhhhh. I can now re-produce the bug now. So, if you put something like <%= jard %>, Jard won't stop at the file, while it works well with <% jard %>. It's an interesting bug, happens with byebug as well. I'll go dive deep to see what happens.

In the mean time, you could use <% jard %> instead.

0x2c7 commented

A debug story: as mentioned above, jard doesn't work with <%= jard %>, while still working with <% jard %>. Internally, ERB compiles the view template into a series of Ruby print statements, then evaluate all the statement with an input binding. This is a test file to point the differences between two approaches:

require 'erb'

str1 = <<-CODE
  <h1>
    <% jard %>
    <% a = 1 %>
  </h1>
CODE

puts ERB::Compiler.new(0).compile(str1).first.to_s
puts "==================="

str2 = <<-CODE
  <h2>
    <%= jard %>
    <% a = 1 %>
  </h2>
CODE
puts ERB::Compiler.new(0).compile(str2).first.to_s

Results:

#coding:UTF-8
print "  <h1>\n    ".freeze
;  jard ; print "\n    ".freeze
;  a = 1 ; print "\n  </h1>\n".freeze

===================
#coding:UTF-8
print "  <h2>\n    ".freeze
; print(( jard ).to_s); print "\n    ".freeze
;  a = 1 ; print "\n  </h2>\n".freeze

So, in the second script, jard is called as an an argument of print method call. Unfortunately, this case is not handled in latest version. This bug is fixed in #37.

Awesome thanks