Design decisions

Favour full-line comments

The heuristic in textobj-comment only looks for full-line comments when doing the upwards search.

Reason: Avoid false positives. Otherwise there are a lot of inline matches we don't want to match.

• In Vim script every double-quoted string would be an inline match.
• In Java, every > would be an inline match because the Java filetype plugin declares it a comment leader.
• ...

Favour simple leaders

Simple leaders at the start of the line match first (before paired leaders).

Reason: Simple leaders seem to be safer in the general case as some filetypes have "strange" paired leaders, e.g. Vim script has s:" -,e:"". We don't want to be confused by those.

Consequences: In the following snippet, ac selects the bottom two lines.

/* Start
// comm[e]nt
// end */

In the following snippet, ac selects the part //m[e]nt */ bar;. The simple leader wins over the paired leader if it starts to the left of the cursor.

int foo = /* com//m[e]nt */ bar;

"ic" selects comment content

The "ic" text object selects the comment content, and more precisely the printable comment content:

    /*
     * What
     */

In this example vic selects just *_What, not \n_____*_What\n____. I believe it is more useful to select the actual content instead of everything between opening and closing delimiter.

• This goes against the design of, e.g. i) or i".

• But it is similar to, e.g. i} in situations like this one:

      if (true)
      {
          oap->q = 45;
      }
  

  Here viB selects just the one line (the "content") between the braces and doesn't include any newlines or whitespace that are also between the braces