Fix #707 (partly)

[andreyorst]

Hi, I've partly fixed #707 issue for Elixir's do: blocks. However there are still some problems, which are also exist in current implementation of def ... do ... end blocks.

With my changes the example from the linked issue no works:

defmodule ElixirExampleOne do
  def func_one do
    IO.puts("hi 1")
  end

  def func_two, do: IO.puts("hi 2")
end

defmodule is correctly matched with the last end. The def func_two, do: IO.puts("hi 2") is completely skipped.

However this will not work:

defmodule ElixirExampleOne do
  def func_one do
    IO.puts("hi 1")
  end

  def func_two, 
    do: IO.puts("hi 2")
end

Now, I must note, that even without my patch, the following construct will not work either:

defmodule ElixirExampleOne do
  def func_one
  do
    IO.puts("hi 1")
  end
end

This is due to the fact, that the check if line based, and we simply check if do is on the same line, which is not strict enough. I'm not sure how one would do a better check, perhaps with a search, but this does not guarantee that we'll find correct keyword, and not something that also can match.

Given that, this PR fixes specifically the def func_two, do: IO.puts("hi 2") case.

[andreyorst]

I've tried a bit to do a traversal search that checks for possible definitions when matching from the end, e.g. like here

def foo(x, y)
  do
  when x, do: y
  if x
    do
    y
  end
end█

And when traversing from the front I think it is possible to get reliable results as we're only searching forward for the end key, but when searching backwards we have to dynamically check what keyword we might need, as end can match with a lot of stuff. Like here, end could have matched with if, then with when then with do and only then with foo, and I can't easilly come up with some heuristics to determine the invariant here. Not suggesing that this is impossible, but I don't know if I can do that reliably enough.

Which actually gets me thinking if Elixir could just match against only do end, and ignore the rest, however this would make impossible to use all the features Smartparens provide like slurping an barfing, so this is not an option.

[andreyorst]

I'm not sure if this can be closed in favor of #1058 or not, as #1058 may not be very optimal, so a solution should instead be built upon this approach. Feel free to decide which implementation suits the project better

[andreyorst]

Now that I've worked out most of the quirks in #1058, I think this can be closed.