feat(comment): Add ignore_surrounding_blank_line

[jrwrigh]

This adds a new feature and parameter to mini.comment.

The goal is that blank lines at the beginning or end of a range are ignored, allowing me to use paragraph text objects to highlight chunks of code to be (un)commented without having to add the extra j/k to remove the blank line from the range.

Originally did this to be a custom fork of mini.comment, but figured I'd see if y'all were interested in it.

• [ x] I have read CONTRIBUTING.md
• [ x] I have read CODE_OF_CONDUCT.md

[echasnovski]

Thanks for the PR!

The goal is that blank lines at the beginning or end of a range are ignored, allowing me to use paragraph text objects to highlight chunks of code to be (un)commented without having to add the extra j/k to remove the blank line from the range.

I don't quite understand the use case here. Does it imply that toggling a comment for a paragraph is done by vap-k-gc? If yes, then this works as expected because ap is a textobject that intentionally includes blank lines.

The textobject for a paragraph without blank lines is ip ("inside" paragraph). So commenting and uncommenting it is only gcip. Additionally, uncommenting can be done by gcgc, which uses gc textobject meaning "all adjacent commented lines".

Does this solve the original usability problem?

[jrwrigh]

My habit when commenting out a few blocks of code (often multiple paragraph textobjects) is to do V]gc where ] is repeated however many times I need to select the chunk of code I need. The ] (or equivalently [) motion moves to the line after the next paragraph, causing the gc to pick up one line to many.

So for example, if I have the following C code:

  if (input > 0) {
    bool something_extra;

    int64 = enum_value;
  } else {
    int64 = -1;
  }

  printf("int64: %ld, enum_value: %d, input: %d\n", int64, enum_value, input);

Let my cursor be at the if keyword and I want to comment out the if statement. I would V]]gc, but normally this would result in

  // if (input > 0) {
  //   bool something_extra;
  //
  //   int64 = enum_value;
  // } else {
  //   int64 = -1;
  // }
  //
  printf("int64: %ld, enum_value: %d, input: %d\n", int64, enum_value, input); 

The extra line at the end is commented even though it's empty. Thus, I can't use [ or ] motions to highlight the same area again to uncomment it.

I recognize the application is niche and mostly due to my own habits. I don't have any qualms with it not being upstreamed (though that would require me to rebase my changes if and when they're updated here).

[jrwrigh]

Additionally, uncommenting can be done by gcgc, which uses gc textobject meaning "all adjacent commented lines".

I did not know about that! That is quite handy, but doesn't fully address my issues with ] and [ motions for navigating code.

[echasnovski]

My habit when commenting out a few blocks of code (often multiple paragraph textobjects) is to do V]gc where ] is repeated however many times I need to select the chunk of code I need. The ] (or equivalently [) motion moves to the line after the next paragraph, causing the gc to pick up one line to many.
...
I recognize the application is niche and mostly due to my own habits. I don't have any qualms with it not being upstreamed (though that would require me to rebase my changes if and when they're updated here).

Yes, I am afraid this is not a strong case for adding a new option. At least for these reasons:

• This can (and my honest suggestion - should) be fixed by adopting more precise selection and/or movements. Like using textobjects for the thing to comment or making custom movement mappings.
• Setting config.options.ignore_blank_line = true is already very close to this behavior:
  • Commenting will ignore adding comment to blank lines. Yes, even if it is in the middle.
  • Uncommenting with gcgc will uncomment all commented lines adjacent to cursor even if there are blank lines in the middle (i.e. they are ignored when computing textobject's range).

So yeah, I am afraid I am going to close this as not planned. Thanks for your time and efforts doing this, though!