Generator star spacing doesn't play nice with cindent

[simonratner]

Requirement for a space after the generator star, in combination with ES6 object literal syntax, makes it impractical to use together with vim's cindent, which is usually the basis of all javascript indenters.

For example, consider:

let Obj = {
  * foo () {
  },
  *bar () {
  }
}

With the cursor on line 2, pressing o in vim to open a new line triggers a builtin cindent multi-line-comment continuation rule, resulting in:

let Obj = {
  * foo () {
    * | <-- cursor position
  },
  *bar () {
  }
}

This does not happen on line 4, since cindent explicitly requires a space after the comment leader to avoid treating pointer dereferences as comments:

let Obj = {
  * foo () {
  },
  *bar () {
    | <-- cursor position
  }
}

I prefer spaces around generator stars when they are used as part of function * genfn (), or any other context, but it would be nice to relax this rule when the * is the first non-whitespace character on a line, to avoid running into this conflict.

See: http://vimdoc.sourceforge.net/htmldoc/change.html#format-comments, default setting for javascript files on my system seems to be: comments=sO:* -,mO:* ,exO:*/,s1:/*,mb:*,ex:*/,://

[feross]

Thanks for opening such a thorough issue with examples. This is an unfortunate bug in vim. :( But I don't think we should change this rule in standard just to accommodate (what seems like a clear) bug in vim. Have you tried opening an issue on the appropriate issue tracker for vim?

(Going to close this issue, but feel free to continue commenting.)

[rstacruz]

long term vim user here... i dont think that'll ever get fixed in vim.

[feross]

@rstacruz Drat... what makes you believe that?

[rstacruz]

the resolution for the * rule (m in set comments) isn't syntax aware. this applies to all languages, not just javascript. it will continue writing * even if it's outside a comment. this is typically painful in CSS when writing * rules. (which is almost never done, but still)

/*
 * aoeu
 * aeou
 */

* aoeu
* aoeu

okay, after reading the docs, now i'm not sure if that's by design or not... but that's just how it's always worked :\

[feross]

So, there's a way to work around it in the CSS case, though. Right?

[rstacruz]

nope!

[feross]

Wait, so you literally can't type the desired text in vim? Or, you just can't do it with the cindent preference enabled?

[dcousens]

Maybe @pangloss from https://github.com/pangloss/vim-javascript could help us?

[rstacruz]

You'll have to type it out, then delete the '* ' afterwards

[simonratner]

I suspect comments is not syntax-aware by design, or at least by conscious omission, limited as this may be. I guess one could write an indent plugin that doesn't rely on cindent and does syntax-aware comment extension, but the common ones don't.

For now, I have hacked a workaround that I find satisfactory (and which should work for CSS, too):

set comments=sO:*\ -,mO:*\ \ ,exO:*/,sb:*,mb:*,e:\ {,s1:/*,mb:*,ex:*/,://

It has a limitations:

1. Unindented comment lines will not be automatically closed by pressing / (the last x modifier), since vim applies the end-piece rule immediately following the first matching mid-piece rule.

2. Unindented comment lines ending with <sp>{ will not insert a comment leader, and will de-indent the following line. This is obviously the whole point of this exercise, but I am mentioning it anyway since it may make typing out code blocks inside comments harder. I happen to always indent code blocks inside comments -- markdown-style -- so it is not a problem in practice.

3. Unindented comment lines which match both the mid-piece and the end-piece utterly confuse the indenter (lines with start-piece and end-piece are ok, so you can still write /* One-liners. */).
   Hopefully, nobody writes comments like this ™:

   /*
    * Foo. */
   

I don't particularly care about (2) and (3). Point (1) is a little annoying, since it will also not de-indent the next line even if you close the comment with <bs>/, requiring one more <bs> (edit: it does de-indent correctly, that was me testing on invalid syntax).

If anyone wants to suggest improvements, I am all ears ;)