begin...rescue...etc blocks

[telemachus]

First, this is an excellent Christmas present. Thanks.

The first file I opened to test the script on had a begin...rescue...end block at the top, and I quickly realized that block selection didn't work on it. My first thought was just to add begin (and maybe also rescue) to the list of keywords for the start of blocks, but things weren't quite so simple. First, because of the way text objects rely on indentation, even with begin defined as a keyword, the block wasn't correctly found. Second, I also ended up wondering how far it would be useful or reasonable to take this. That is, would you want to define begin, rescue, retry, else and ensure so that each could be its own sub-block? I'm not honestly sure how to handle this, but I wanted to mention the issue.

[nelstrom]

Thanks for raising this. I think that begin should certainly be added as a block delimiting keyword.

As for else/rescue et. al., I'm not so sure. At the moment, I consider if/end to be a block, regardless of whether there are else/elsif branches within it. It makes sense when you select all of the block (var), but it doesn't make such terrific sense when you select inside the block (vir).

By the way, the rubyblock plugin does not depend on indentation. Instead, it uses the searchpair function, which searches forwards for the first 'end' keyword whose matching opener (module/class/def etc) has not already been encountered.

[telemachus]

By the way, the rubyblock plugin does not depend on indentation. Instead, it uses the searchpair function, which searches forwards for the first 'end' keyword whose matching opener (module/class/def etc) has not already been encountered.

Ah, ok. I still suspect that indentation is involved somehow (perhaps in searchpair itself then?), since in tests here, the plugin doesn't work at all on files that have no indentation or improper (unbalanced) indentation. For example, if I take the module...class...def block that you use in the readme and remove all its indentation, then both var and vir select the final two ends (if the cursor starts on the top or bottom of the block).

But maybe I'm misdiagnosing this, and it's the result of another plugin interaction on my side. I'll experiment some more here, but please let me know if you don't get the same results with all indentation removed.

[nelstrom]

For me, the rubyblock text object works fine when the indentation is flattened. I've recorded a short screencast to prove it: http://screenr.com/Hvu

To help diagnose the problem, could you tell me the version of Vim you are running as well as the version of matchit.vim?

Run :version to find out which Vim you're on. Run :edit $VIMRUNTIME/macros/matchit.vim to open the matchit plugin, which includes the version number in the first few lines.

I am running Vim 7.3, with matchit.vim 1.13.2.

[telemachus]

Thank you very much for helping me to debug this, and I apologize for having wasted your time (and confused a few other issues by mentioning indentation).

By cleaning out my environment and then slowly putting pieces back, I found the culprit: ruby-matchit. It's a plugin that I had forgotten I was even using, and it does rely on indentation. In addition, it was getting in the way of your plugin. I've removed it and all is good. I'm going to close my other issue, and again thanks for your patience and sorry for wasting your time.

[nelstrom]

Aha!

Comparing the release history of matchit.vim and ruby-matchit.vim, it looks as though matchit both pre-dates ruby-matchit, and has continued to be supported for longer. Presumably the author of matchit.vim added support for ruby syntax after ruby-matchit came along, rendering the latter obsolete.

No need to apologise. I'm sure that other people will face this problem too, so it's good that you figured out what was causing difficulty.