[ruby] (lack of) handling of comments within blocks breaks code about splitjoin.vim HOT 10 CLOSED

Yeah, comments are tricky to handle.

My original reason for ignoring them is that I felt it's not difficult to migrate comments first and then do the join. That's because I usually write them like this:

if true
  # comment
  method!
end

A dd, followed by a join, followed by a P, works great.

Unfortunately (for me), it seems like the "trailing comment" style is also popular :). It makes sense to try to figure something out.

On the technical side, it might not be that hard, actually. We handle comments in vim-ruby with a simple regex and it seems to work out pretty well. Then again, we don't extract them afterwards, so it's hard to say whether I'll have more trouble there. Still, I think it's doable.

The bigger problem is the edge cases, like having multiple comments:

if condition? # then we want to do the following:
  call_method # TODO rename this
end # END IF

All three locations can be commented and it's not obvious how to merge them. The options I see:

• Discard most of them. Keep just one, maybe. This seems like a bad solution, since we're destroying information. It could be argued that this should be migrated before joining anyway, since there's no way for it to fit. And there's always undo. Still, seems a bit too heavy-handed.
• Move them all above. This means that splitting afterwards will not restore it to its original state, but I wouldn't say that's a particularly bad thing. If you change your mind soon after, it makes more sense to undo anyway. Still, moving them all above will probably discard information. The comments used to be at these places for a reason, dumping them all in one place probably doesn't make sense.
• Don't join. I think I like this option best. Instead of trying to guess, we just do nothing, except show a message at the bottom that says "Don't know what to do with the comments, please remove them."
• Don't join, unless there's only one. Like the above, except if there's just one comment in one of these places, migrate it to the end of the newly-joined line.

What do you think? Either way, I'd have to add some additional logic to detect and strip comments. I'll see when I can find the time to implement this, along with working on issue #30.

from splitjoin.vim.

I'd lean towards the last option. And possibly warn if there are more than one comment.

Moving the comments above the code would work too, more so in my case since I prefer to keep comments out of the code blocks. Inline comments shouldn't be required anyway, since each line should be self explanatory.

And then there are the corner cases where you have to put the comment inline (to make it a control code for other apps, like rubocop) and that way break every rule in the book :)

I would prefer if splitting after join would produce the same output as the original, but this might be one of the cases where it's not reasonable to expect that.

from splitjoin.vim.

I've finally gotten some work done on this feature. Sorry to take so long.

I've pushed a commit that handles comments in three different cases: if-clauses, do-blocks and ternary operators. For other cases I've skipped it at this time, because it was either more difficult to implement, didn't seem like an important use case (case blocks should be fine with inline comments as it is), or both.

Could try it out and let me know how it works for you? Do you think there are splitjoin patterns that I haven't covered that are important to cover?

from splitjoin.vim.

Nice, I tried with a few variations that I commonly encounter and looks like it's working properly.

I also tried the following which fails with an error, but ends up with a broken output:

if true
  true # do it
else
  false # Don't do it
end

Which results in this output after displaying the error:

if true  true # do it
else
  false # Don't do it
end

from splitjoin.vim.

Hmm, that's odd. It seems to work just fine for me. When you say "it fails with an error", you're referring to the "can't join due to comments" message, right? Not an actual Vim error? Also, where are you trying to perform the join, on if true, somewhere else?

I've just pushed a branch, debug-issue-31, where I've added some debugging information. Could you try it with that branch and paste the message output? If it doesn't show up, execute the :messages command, that should do it.

from splitjoin.vim.

Sorry, I should never type something in a rush. I meant that it displays the message about not joining.

So when I talk about the error, you should assume it means the "can't join due to comments" message. The only problem is the output. If you try to join (with gJ) on the first line, it will result in the output of the second example.

One would assume that the file would remain unchanged when the clause cannot be joined due to comments.

from splitjoin.vim.

Ah, of course! Now I know what the problem is and why I'm not getting it. The gJ mapping does something slightly special, falling back to the default behaviour of gJ if nothing matches... I'll see what I can do.

from splitjoin.vim.

I've just pushed a commit that should fix the problem. Could you test it out?

from splitjoin.vim.

Nice.

The update fixes the problem and even that minor inconvenience is now gone. This issue can be closed.

from splitjoin.vim.

👍

from splitjoin.vim.