Heredoc syntax highlighting is broken for Ruby

[dkali]

The regression was introduced by the PR #466

Now all the code in a file is highlighted as a sting after the heredoc formatted method call:

This behavior has seriously impacted the SublimeText usage on the projects where heredoc method calls are used oftenly, so I have to revert the change in the Ruby.sublime-syntax file or stay on the build 3114 where it was working.

On build version 3114 syntax highlighting was working slightly better, but still not fully correct. First text variable was highlighted correctly, but rest of them not. But at least it was not ruining the highlighting for the rest of my code.

p.s.: issue discussion on forum: https://forum.sublimetext.com/t/herodoc-text-format-is-broken/24266/2

[wbond]

Can you post the raw code so I don’t have to re-type it?

[dkali]

func(<<-var1, <<-var2, <<-var3)
  some text 1
var1
  some text 2
var2
  some text 3
var3

h = {a: 1, c: 2, r: 3}

[dkali]

Could you please elevate the priority for this Bug? It greatly impacts user experiense.

[flatrocks]

Current operation is much better than originally reported in this thread but this problem remains in version 3.1.1, Build 3176:

In squiggly heredocs and (regular ones, too,) included #{...} string interpolation syntax is displayed erratically, sometimes as a comment, sometimes not, depending on context within the HEREDOC string.

This example works correctly (that is, it behaves as expected when executed via Ruby 2.5,) interpreting all the interpolations and resulting in the correct string value.

[michaelblyons]

RE Original report: It's not immediately apparent from the screenshot, but Sublime is trying to pop the HEREDOCs from the stack LIFO.

func(<<-var1, <<-var2, <<-var3)
  some text 1
var1
  some text 2
var2
  some text 3
var3
# still in "var2"
var2
# still in "var1"
var1

# Now we're free

h = {a: 1, c: 2, r: 3}

RE second report: plaintext below

sql = <<~SQL
    #{ITEM_SELECT}
    WHERE sku = '#{sku}'
SQL

[deathaxe]

With regards to the original error report:

Sublime Text's syntax engine can't handle multiple HEREDOCs at a line. I tried to implement it for Perl before, but you just can't do it proberly because HEREDOCs don't push/pop in a linear style.

We'd need a new engine feature for it.

With regards of the secondreport:

This issue is partly fixed by #2054, but might not yet work for all supported embedded syntaxes in any situation. It's tricky (and currently a bit dangerous) to inject the interpolation support into an embedded syntax as the required with_prototype is well known to easily cause recursions.

[skalee]

How about (un)indented-heredoc-end popping all remaining heredocs contexts, if any? That would be far from perfect, obviously, but at least would fix syntax highlight in the trailing part of file.

[jjb]

status in 2024:

Sublime

VS Code

broken for first one, works for second 2, ends correctly 🤷

gist published

gist editor

works better than published 🤷

[deathaxe]

Not sure, what the intention of those huge screenshots is, but this kind of heredocs is not possible with ST's syntax highlighting engine.

[jjb]

Heh, sorry about large images - was just curious myself how they all compare so I thought I would document it, maybe someone in future might have an idea of how logic could be borrowed from one of the other engines.

[deathaxe]

The logic how to do it has already been out-lined by a former sublimehq dev. It would require a rather specific syntax engine logic and syntax definition syntax for just this single use case. As there are only very few syntaxes left these days making use of heredocs, it seems rather unlikely to be supported anytime soon.

[jjb]

Gotcha - thanks!