Indentation is wrong inside function with multi-line parameter list

[gjm-lbo]

Consider the following code:

function functionWithLongName(numberOfWidgets,
                              numberOfWadgets) {
  // ... code goes here ...
}

On hitting Enter after the {, the cursor is placed not one shift-width in from the left, but one shift-width in from the start of the numberOfWadgets line (i.e., the line on which the { occurs). Any new line created within the function body (but not within another {...} block) gets the same treatment.

This is not actually specific to function definitions; the same happens with the following code.

while (functionWithLongName(variableWithLongName)
       || a < b) {
  // ... body goes here ...
}

Of course this problem goes away if you use "Allman" rather than "1TBS" style and put the {s on their own lines (because the {s no longer occur on abnormally-indented lines), but it seems unfortunate for Vim to enforce that decision.

It seems like the "right" behaviour is something like:

• Find the line with the enclosing {
• Combine it with as many previous lines as are needed to avoid an excess of closing delimiters
• Use the whitespace at the start of the resulting combined line as base for indentation
• Use that combined line for identifying control structures that need special treatment, like switch

but maybe there's a better way.

[bounceme]

Sorry, but this is deliberate. much more discussion has happened already #683 (comment)

[gjm-lbo]

I read through #683 and its predecessor #621 and while there was lots of discussion of some other issues, all I found about this one was a statement that you prefer this behaviour and don't intend to change it. Did I miss an explanation of why you prefer it?

If I didn't, then -- and I'm sorry for poking at something you've already said you don't intend to change -- is there any chance you could at least explain your reasoning a bit? For the avoidance of doubt, I'm sure you have excellent reasons, but right now I can't think of any circumstances in which anyone would want anything like

function foo(multipleLongVariable, namesRequiringMultiline,
             parameters) {
               doSomething();
               doSomethingElse();
             }

which is the indentation this produces.

(My apologies for not checking whether this was already in the closed issues before filing a new one. It simply hadn't occurred to me that it could be considered correct behaviour!)

[bounceme]

my results ( and jsbeauitfy results ):

function foo(multipleLongVariable, namesRequiringMultiline,
  parameters) {
  doSomething();
  doSomethingElse();
}

this was one where i think instead of code style debates (everyone loses), it's better to just try and reproduce something like jsbeautify

[gjm-lbo]

First of all, what Vim 8.0 does for me (is this changed in some very recent development version? indent/javascript.vim says it was last changed on 2016-08-25) is different:

function foo(multipleLongVariable, namesRequiringMultiline,
  parameters) {
    doSomething();
    doSomethingElse();
  }

But never mind that. I agree that jsbeautify will never format the parameter list in a way that provokes the issue I reported. So are you arguing (1) that it doesn't matter how Vim indents such code, because coding styles that don't duplicate jsbeautify output are unsupported and you don't care what happens to people who use them, or (2) that the indentation Vim actually produces is better in these cases?

I'd thought it was the second of those, but obviously an appeal to jsbeautify can't support any preference about how to indent code in contexts that jsbeautify could never produce.

I agree that everyone loses in code-style wars, and wasn't intending to get into one. I can't see how Vim's current JS indentation (in this admittedly slightly corner-case-y situation) fits any coding style I've ever heard of.

[bounceme]

Oh, if you want the new behaviour, you need to use the indent script in this repo ( it is still in development, so there changes not present in vim/vim).

[bounceme]

I assume everything worked out, no?

[gjm-lbo]

Ah! With the version in the repo the behaviour is "correct" (i.e., in line with my expectations). So I'm very sorry; it seems I filed a bug report against an obsolete version of the code, and presumably what you were saying was deliberate isn't the same as the behaviour I was describing. Confusion all round. Sorry about that; and thanks for, as it turns out, already having fixed the bug :-).