Discussion:
Is it possible to use __END__ in .erb file?
Wolf
2018-07-31 13:57:55 UTC
Permalink
Hi,
I would love to use __END__ / DATA in my .erb file (executed
via `erb file.erb`. I've tried

<html>
<head />
<body>
<%= DATA %>
</body>
</html>
<%
__END__
foobar

but that does not work

Traceback (most recent call last):
5: from /usr/bin/erb:170:in `<main>'
4: from /usr/bin/erb:149:in `run'
3: from /usr/lib/ruby/2.5.0/erb.rb:858:in `run'
2: from /usr/lib/ruby/2.5.0/erb.rb:876:in `result'
1: from /usr/lib/ruby/2.5.0/erb.rb:876:in `eval'
genki.html.erb:4023:in `<main>': uninitialized constant DATA (NameError)

Is it possible to do this somehow?

W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Ralph Shnelvar
2018-07-31 14:04:36 UTC
Permalink
Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Wolf
2018-07-31 14:21:51 UTC
Permalink
(a) You probably want to ask this in
I'm not sure what relation to rails is here. I'm using the
standalone `erb` executable that comes with ruby out-of-the-box.
Though I have no idea, is that something made by rails people?

Or do rails people just have more experience with this particular
executable?
(b) Almost anything is possible in an .erb file. What are you trying to
accomplish?
I'm trying to work around slow syntax highlighting in vim. It does not
really play nice with this long heredoc I have in my file (it's *really*
slow), so I thought moving it into __END__ could help with that.

But did not found a way to do it so far :/

W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Andy Jones
2018-07-31 14:47:24 UTC
Permalink
I'm trying to work around slow syntax highlighting in vim. It does not really play nice with this long heredoc I have in my file (it's *really* slow), so I thought moving it into __END__ could help with that.
<<<<

Are you by any chance using jRuby? If you are, vim will use jRuby too, which might be slower. (It used to be a lot slower, but these days not so much).

If this is the cause of the slowness, try adding this to your .vimrc: "autocmd FileType ruby compiler ruby"

(At least I _think_ that was how I fixed it here. I've lost the note I made. But it's there in my .vimrc.)




Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>

Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Wolf
2018-07-31 14:54:10 UTC
Permalink
Post by Andy Jones
Are you by any chance using jRuby? If you are, vim will use jRuby too, which might be slower. (It used to be a lot slower, but these days not so much).
If this is the cause of the slowness, try adding this to your .vimrc: "autocmd FileType ruby compiler ruby"
Using MRI. I think it's more likely that it just does not like the fact
that the heredoc is 3.5k lines long...

W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Andy Jones
2018-07-31 15:01:51 UTC
Permalink
Using MRI. I think it's more likely that it just does not like the fact that the heredoc is 3.5k lines long...
<<<<

!!!!!

I can think of some other reasons to not do that. Does someone have to maintain this file?


Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>

Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Wolf
2018-07-31 17:42:21 UTC
Permalink
Post by Andy Jones
I can think of some other reasons to not do that. Does someone have to maintain this file?
Well, I do. But I don't think there are any maintainence as far as the
heredoc goes. What is a pain is syntax highlight being slow on that. So
I would like to move it into __END__ section (where it works just fine)
however cannot figure out how to do that in .erb file.

W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Jonathan Harden
2018-07-31 18:11:30 UTC
Permalink
Hi Wolf,

I'm not sure I can help with the specific question, but as for slow syntax
highlighting in vim if you are on vim8 I could recommend moving to ALE. I
moved from syntastic to ALE since ALE is asynchronous, with syntastic when
I opened large files I had to wait while the linter was run before the file
would open, with ALE the file opens, and after a few moments the linter
hints appear, for me this feels a lot less like an interruption in my
workflow.

Ale home: https://github.com/w0rp/ale

Hope this helps
Post by Andy Jones
Post by Andy Jones
I can think of some other reasons to not do that. Does someone have to
maintain this file?
Well, I do. But I don't think there are any maintainence as far as the
heredoc goes. What is a pain is syntax highlight being slow on that. So
I would like to move it into __END__ section (where it works just fine)
however cannot figure out how to do that in .erb file.
W.
--
cache invalidation, naming things and off-by-one errors.
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Andy Jones
2018-08-01 07:24:00 UTC
Permalink
Thinking outside the box here ... But you could move the contents of that heredoc to ... a separate file?

* Solves your highlighting problem

* You say the bit you need to maintain of that program is not the heredoc, so that would make maintenance easier.



-----Original Message-----
From: ruby-talk [mailto:ruby-talk-***@ruby-lang.org] On Behalf Of Wolf
Sent: 31 July 2018 18:42
To: Ruby users
Subject: Re: Is it possible to use __END__ in .erb file?
Post by Andy Jones
I can think of some other reasons to not do that. Does someone have to maintain this file?
Well, I do. But I don't think there are any maintainence as far as the heredoc goes. What is a pain is syntax highlight being slow on that. So I would like to move it into __END__ section (where it works just fine) however cannot figure out how to do that in .erb file.

W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>

Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Marvin Gülker
2018-08-01 16:55:10 UTC
Permalink
Post by Wolf
Well, I do. But I don't think there are any maintainence as far as the
heredoc goes. What is a pain is syntax highlight being slow on that. So
I would like to move it into __END__ section (where it works just fine)
however cannot figure out how to do that in .erb file.
ERB is not a normal Ruby file. I don't have insights into how the ERB
library processes RHTML (which is how the format is called), but it
certainly uses neither #require nor #load. Most likely something with
#eval, and #eval won't coöperate with __END__.

irb(main):002:0> eval "p DATA.read\n__END__\nfoo"
NameError: uninitialized constant DATA
Did you mean? Data
from (irb):2:in `eval'
from (irb):2:in `eval'
from (irb):2
from /usr/bin/irb:11:in `<main>'
irb(main):003:0>

That being said, the solution for your "problem" is:

1. Put the string in a seprate file and read the file in, or
2. Disable syntax highlighting in your editor for your ERB file.

I'm an Emacs user and don't know how to do 2), but I'm sure somebody
here on the list will give you a hint.

Marvin
--
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin
Continue reading on narkive:
Loading...