indent: handle consecutive linebreaks

[bcgraham]

Fixes #2094

[bcgraham]

Should these also have comments, like in_string?, end_of_statement? etc?

[banister]

@bcgraham you seem on the ball - wouldl you llke a commit bit?

EDIT: given

[bcgraham]

@banister Thanks, appreciate it 🙏.

Not sure on etiquette or team culture around committing, so to err on the side of overclarifying:

1. To avoid churn/reverts, if the checks have passed and my best judgment is to merge the PR (using normal heuristics for merging to a professional, production project: links associated issue if there is one and it makes sense, tests any functionality changes if it's not a trivial change, etc.), should I feel free to merge?
2. Should I limit this to only some kinds of PRs, like only my own, or definitely not my own (to get another set of eyes on it)?

[kyrylo]

This description doesn't reflect what we are trying to test here. Without context this test looks weird: we pass already indented code and verify that it's still indented. Nothing wrong with this kind of test per se but the description could be more clear.

1. Avoid should, just say it 'properly indents...'
2. Since input is the same as output, I would make it a variable and reuse in the expectation
3. I would change the description to say something like "given already indented code it returns self". That is, Indent didn't make any changes

Hope that makes sense.

[bcgraham]

1. Avoid should, just say it 'properly indents...'

👍. This was to be consistent with the surrounding descriptions, but I agree with avoiding should in this manner. Changed to reflect this guidance.

2. Since input is the same as output, I would make it a variable and reuse in the expectation

It's hard to see on GitHub, but the empty line on 111 becomes a line with two spaces on 124. Inserting hash signs (as specified in the comment at the top of the file) affects the test case, since the test case is about empty lines.

Given that context, what would you think about

input = [
  'class C',
  '  def foo',
  '    :foo',
  '  end',
  '',
  '  def bar',
  '    :bar',
  '  end',
  'end'
].join("\n")

output = [
  'class C',
  '  def foo',
  '    :foo',
  '  end',
  '  ',
  '  def bar',
  '    :bar',
  '  end',
  'end'
].join("\n")

to prevent accidental editor whitespace linting, or something like

output = input.lines
output[4] = '  ' + output[4]
output = output.join

to express the diff between input and output? For now, I updated to the second one.

The above snippets are attempts to give you something concrete to comment on or perhaps say "yes" to, but ultimately, my preference here is "whatever @kyrylo & other maintainers prefer".

my_disposition.mp4

3. I would change the description to say something like "given already indented code it returns self". That is, Indent didn't make any changes

This makes sense 👍; your example description for the submitted code is clearer than the original. I'm making this change. Let me know if, given your thoughts of the above, I should update the description (while keeping it clear!).

[bcgraham]

Not a fan of how GitHub manages PR discussion/changes, so I isolate changes resulting from PR feedback in their own commits, to be squashed prior to merging.

[bcgraham]

Took another gander at this and realized it could be simpler. I put together a version that returned the original input, e.g.

expect(@indent.indent(input)).to eq input

but found it actually made another test fail!

# spec/commands/play_spec.rb, line 36
describe "playing a file" do
  it 'should play a file' do
    @t.process_command 'play spec/fixtures/whereami_helper.rb'
    expect(@t.eval_string).to eq unindent(<<-STR)
      # frozen_string_literal: true             # <-- fixture has newline after this line, indenting removes
      # rubocop:disable Layout/EmptyLineBetweenDefs

Let me know if you feel better about this change.