Heredoc improperly highlighted.

[envygeeks]

Rails.logger.error("\s\s" + <<-STR.strip_heredoc.strip)
  #{error_.message}: #{error_.backtrace[0]}
STR

The result is that the end ) is the same color as the string. (Actually this seems to be a bug inside of Pygments too since it seems to do the same thing.)

[envygeeks]

@kevinsawicki also adding that this ends up in some funky highlighting of everything after the heredoc:

<<-SQL
"
SQL

It doesn't happen with STR but it does happen when invoking SQL, Liquid and others!

[ryanmt]

[nocash]

:disappointed:

I would expect line 3 to use proper highlighting at , locals: { params: params }. In Vim:

[stevenpetryk]

).where(blackout_dates: { id: nil }) is all highlighted as SQL.

[50Wliu]

I'm not sure this is obtainable using regex.

[SamGerber-zz]

I tried playing around with this and learned a few things:

1. There are a few different rules that apply to heredocs: a. vanilla heredoc: https://github.com/atom/language-ruby/blob/d88a4cfb32876295ec5b090a2994957e62130f4a/grammars/ruby.cson#L1817-L1838 b. special heredocs that signal other languages (HTML, XML, SQL, GRAPHQL, CSS, CPP, C, JS, JQUERY, SH, LUA, and RUBY): https://github.com/atom/language-ruby/blob/d88a4cfb32876295ec5b090a2994957e62130f4a/grammars/ruby.cson#L1409-L1816 c. a more complicated vanilla pattern that covers opening multiple heredocs in the same line: https://github.com/atom/language-ruby/blob/d88a4cfb32876295ec5b090a2994957e62130f4a/grammars/ruby.cson#L1839-L1861

Though Atom's guide for creating a grammar is still WIP, the TextMate Manual is very helpful.

For most cases, it shouldn't be too hard to fix things. If we add a capture group for the remainder of the line, we can apply a beginCapture pattern to include source.ruby for that group.

This naive approach broke down for me when I tried to adjust the rule for multiple heredocs per line. For example, this bit of code:

<<-ONE + <<-TWO
  Hello,
ONE
  world!
TWO
# => "Hello, \nworld!\n"

I could sort of approximate the right behavior here, but ran into some hurdles. I think we'll have to settle for something less than perfection here, because:

the regular expressions are matched against only a single line of the document at a time. http://manual.macromates.com/en/language_grammars#language_rules

[envygeeks]

I don't settle for bugs, so: no.

[50Wliu]

@envygeeks then you'll need to test #225, because as @SamGerber and I have both discovered you'll be waiting here forever if you want a bug-free regex fix. Though I should say that your attitude is pretty discouraging for someone who just wants to help out :/.

[envygeeks]

I didn't say it had to be a "bug-free regex fix", I didn't even mention regex at all; I said, I don't settle for unfixed bugs, or being told that bugs can't be fixed. And my "attitude" is not discouraging, stop trying to shame people because they dissent to an opinion expressed.

And I am happy to test #225, but that pull-request states no way to test it, without having to build my own package, and ship into Atom editor, manually, I think it there were a beta pipeline for such testing then my comment would have never of been made in the first place as I would have traced it back here and tried it already, and started commenting.

[willcosgrove]

Since this issue has been open for over three years now, I would welcome even a partial fix at this point. I agree, I don't want to settle for a partial fix indefinitely, but @SamGerber's proposed solution would solve the problem for a majority of cases.

[hovsater]

Is there anyone looking at this? Is there anything I can do to help move the needle forward?

[lee-dohm]

@envygeeks and @SampsonCrowley your comments were deleted as a violation of the Atom Code of Conduct as they were insulting or derogatory. You may both consider this an official warning.