Trailing missing `end` bad results

[schneems]

class Dog
  def bark
    puts "woof"
end

Gives me:

    ❯ 1  class Dog

Which is not correct. In this case ruby -wc does know the lines are off

$ ruby -wc  bad.rb
bad.rb:4: warning: mismatched indentations at 'end' with 'def' at 2

The reason this happens is the end is ambiguous, but just slightly. The algorithm thinks it's a mis-indentation and that the class is really missing the value. I would say that the output, isn't very good as it should capture the matching end in the "context" expansion at bare minimum.

To see just how much of an edge case this is:

Removing the puts line produces the correct results:

      1  class Dog
    ❯ 2    def bark
      3  end

Also adding a method after it produces the correct results:

      1  class Dog
    ❯ 2    def bark
      4    def blerg
      5    end
      6  end

Investigating

Running with DEBUG=1 this is an unexpected first step. I think that's a bug:

      1  class Dog
      2
      3    def bark
      4      puts "foo"
    ❯ 5
      6  end

It might be better without it

Moving forwards

• Fix the output in the case where the class Dog is being shown to be removed
• Investigate the strange first step above, then make plans to further remediate.

[schneems]

Fix the output in the case where the class Dog is being shown to be removed

The reason this happens is the "bad block" captures the entire code contents

Running with DEBUG=1 this is an unexpected first step. I think that's a bug:

This happens because of the difference of an internal versus external scan on the frontier (generative versus expansive). The generative modes grabs all lines until it finds an increase in the indentation including empty lines. Filtering out this doesn't change the results.

[schneems]

This is a harder case to handle as ruby -wc gives no warnings on it:

class Dog       # 1
  Foo.call do   # 2
    puts "woof" # 3
end             # 4

[schneems]

I'm thinking that this case is like the inverse of this case:

Foo.call
  def foo
    puts "lol"
    puts "lol"
end # one
end # two

In this Foo.call case we want out output to include Foo.call as well as the end # two since that's where the error is.

class Dog       # 1
  Foo.call do   # 2
    puts "woof" # 3
end             # 4

If we modify this code to not grab the end on line 4 then the above example starts failing.

[schneems]

I think that in this case, it's ambiguous which is the problem ( to the computer) though maybe not to a human. Here's a case of where i'm at now and where I might want to be in the future:

Deleting line 148 on the rexe.rb example gives us this (instead of pointing to def format_requires)

       16  class Rexe
       18    VERSION = '1.5.1'
       20    PROJECT_URL = 'https://github.com/keithrbennett/rexe'
    ❯  77    class Lookups
    ❯ 152    class CommandLineParser
    ❯ 418    end
      551  end

This isn't great because the output doesn't show def format_requires which is where the error is. Ideally I would want the output to include:

       16  class Rexe
       18    VERSION = '1.5.1'
       20    PROJECT_URL = 'https://github.com/keithrbennett/rexe'
    ❯  77    class Lookups
      140      def format_requires
      149    end
    ❯ 152    class CommandLineParser
    ❯ 418    end
      551  end

Now the question is how could we get there? In the case where a keyword "grabs" the last end of an outer block, the algorithm still has useful information. It is able to figure out "which" block contained it (give or take). In this case it knows the problem is between line 77 and 418.

It wouldn't be awful if we showed this output either:

       16  class Rexe
       18    VERSION = '1.5.1'
       20    PROJECT_URL = 'https://github.com/keithrbennett/rexe'
    ❯  77    class Lookups
      140      def format_requires
      149    end
    ❯ 152    class CommandLineParser
      287      def parse
      417      end
    ❯ 418    end
      551  end

Here's one way we could get there: Show all ends from beginning of block to end of block with the exact same indentation. Moving backwards from there show the next indented kw and end combo. I think it would give us this output ^^ though the selections are inversed.

Alternatively we could try some approach like re-searching the identified "bad" block from scratch somehow. Maybe we reverse the search, or maybe since we know this is an edge case that we just see if the last kw has a matching end and if not, then try parsing it or something? Honestly the less clever we can be the better, it means the process will be more robust.

I think starting with the minimum of "how do we show the problem lines" even if we don't mark them, is a good first step. Either that will prove to be robust enough, or it will facilitate more understanding of the problem space.

Also as a side note, if I comment out line 148 but don't delete it I get the right results:

       16  class Rexe
       40    class Options < Struct.new(
       71    end
    ❯  77    class Lookups
    ❯ 140      def format_requires
    ❯ 149    end
      153    class CommandLineParser
      419    end
      552  end

In true goal-seeking algorithm tradition, I have no idea why.