Broken % command?

[benhamill]

I have a ruby file called foo.rb:

1  foo("thing thang") do
2    some.code("here do")
3  end

If I put my cursor on line 3 and hit %, it should jump to the end of line 1. Instead, it jumps to the end of the string in line 2. I did a binary search through my .vimrc and figured out that when I comment out this line, the expected behavior returns.

I noticed this when writing RSpec examples when it "doesn't do anything" and it "adds the header to the array for the existing record". Both "do" and "for" caused % to freak out.

I have no idea what might cause a color scheme to have this kind of effect, but...

Anyone else replicate this or have an idea of what might be the cause? Or where, at least, to start poking around in this code base to find something?

[rking]

This will be an interesting puzzle to solve (I myself don't have enough time on a computer to solve it, these days).

There is a complex interrelationship between the parts involved. One avenue would be to disable the "Rainbow Parens" part of detailed.vim and see if that fixes the behavior. I had trouble with it interacting with rails.vim and had to shim its loading in at just the right time. I had a conversation with tpope about it, and he seemed hesitant to adjust anything in rails.vim since the whole load sequence was painful to get right to begin with.

I do not mean this to sound like a warning to stay away from it - by all means, anyone can dive and and figure this out - but only as a heads-up that this will require tinkering.

If you come up with something that works just go for it, and we can sort out side effects later.

[benhamill]

I'm beginning to dig into this a little, and I'll put notes from my exploration here, in case anyone else wants to follow me. I'm working with a small test file that looks like this:

foo("thing thang") do
  some.code((((("here do")))))
end

The extraneous nested parens are just to make it more obvious to me that the nesting is off. The first thing I tried was going to line 67 and commenting it out. Sure enough it turned the parens all the same color... but % didn't get fixed. Similarly, if I comment out both line 67 and the entire definition of fatpacked_rainbow_parens. I'm going to try binary searching this thing as a brute force method of testing. I don't expect it'll be pretty.

[benhamill]

Wow. I got lucky and seem to have narrowed it down right fast. It's line 743. If I comment this out, things seem OK. Seeing that the line said something about strings, I changed my test document to

foo("thing thang") do
  some.code((((("do")))))
end

foo("thing thang") do
  some.code(((((:do)))))
end

And, sure enough, the :do symbol doesn't confuse things whereas the "do" string does. Also, a 'do' string doesn't confuse things, either.

So. Interpolated strings it is. I don't know anything about vimscript, so the first thing I'm gonna learn is how to read this line, so I can figure out what it's actually about.

[benhamill]

More information: If the block is made of curly braces, it also gets confused:

foo("thing thang") {
  some.code((((("{")))))
}

I thought it might have something to do with the contains directive of the line, but when I changed it to NONE, it didn't seem to have an effect. I also experimented with removing the matchgroup directive and the skip directive. Neither had an effect.

[benhamill]

Well... I narrowed it some more. It has something to do with the group name being detailedInterpolatedString and not rubyString. When I changed the line to this:

  syn region rubyString matchgroup=detailedInterpolatedStringDelimiter start="\"" end="\"" skip="\\\\\|\\\"" contains=@rubyStringSpecial,@Spell fold

it works OK. I have no idea if this would have additional fallout, though, as far as altered behavior.

[benhamill]

Also, I just noticed that putting a do in there also confuses things, and since that's meant to be a different color from strings, generally, it becomes more clear what the fallout might be for the quick fix...

[benhamill]

There's the code that makes it "work". This isn't an actual fix. I'd love to see if this jogs any good ideas out of someone more experienced.

[benhamill]

@wwalker I haven't looked at this in ages, but I've learned a little bit about Vim syntax files since then. I don't really have an opinion about forks or not forks or whatever. Is @rking completely MIA? Like, if someone forked it, would they have to change the name in order to publish to vim scripts?

[wwalker]

I've not seen RKing or heard about him for nearly two years.

He lived here in Austin, so I actually saw with him a couple of times at ruby events

Could just start a similar project.

[benhamill]

Cool. I'm up for whatever. I have push access to this repo, so if you fork this, let me know, and I can make a big note at the top of the README that the new thing supersedes it.