Minor Formatting Issues

[esidegallery]

I am really loving the new Formatting feature, Josh! There are a few anomalies I noticed, that I can't seem to find a solution for.

This isn't always how I structure my code, but in cases when there are many or long function arguments it is necessary:

The default new-line functionality in VS Code is what I believe one can expect for the structure of code above, however asformat creates an additional indentation for the array contents. For function calls nested within arrays, this indentation is apparently flattened.

Also, the function call closing brackets seem to be indented by one tab extra, though maybe that's the convention.

In MXML files, the opening script tag is de-indented for some reason. (I'm also guessing AS formatting within this tag isn't supported)

Thanks!

[joshtynjala]

the function call closing brackets seem to be indented by one tab extra, though maybe that's the convention.

If a statement spans multiple lines, all lines after the first one are indented one extra tab more than the first one.

It could be argued that function arguments should be indented an extra tab beyond the parentheses. However, I'm not sure if the token stream differentiates ( and ) in function calls from other uses. If there's no specific awareness of function calls, then it could be tricky to do that. On the other hand, maybe if there's any open parenthesis before a new line, it could add an extra tab. That would be more doable. I'll need to play around with it.

creates an additional indentation for the array contents

I think that this is pretty much the same as above. The lines after the first are indented one extra tab. In this case, I think that there's an extra indent for Array items inside [ and ] too. Or maybe just an extra indent for an open [ bracket before a new line.

For function calls nested within arrays, this indentation is apparently flattened.

Yeah, it would probably look better if this nested function call's arguments were indented. Again, an extra tab for open parenthesis could cover that.

In MXML files, the opening script tag is de-indented for some reason. (I'm also guessing AS formatting within this tag isn't supported)

Hmmm... ActionScript embedded in MXML is supposed to be formatted too. I just gave it a try in one of my projects, and I can't reproduce the issue. For me, the Script tag is indented properly, and the AS3 inside is formatted. Is there any chance that you might have another formatter for XML that is conflicting?

[esidegallery]

Thanks Josh - what you're saying about parentheses and multi-line statements makes sense.

About the MXML - asformat is definitely the active formatter. This is set in global settings with the following:

    "[mxml]": {
        "editor.defaultFormatter": "bowlerhatllc.vscode-as3mxml"
    }

And I can see the change in formatting when I enable/disable as3mxml.format.mxmlAlignAttributes.

I am using Windows - don't suppose that could be it.

When I get the chance, I'll try a fresh install with just as3mxml installed and get back to you.

[joshtynjala]

I am using Windows - don't suppose that could be it.

It seems unlikely. Although, I guess I should double check that I correctly deal with line endings.

About the MXML - asformat is definitely the active formatter.

Can put together a very simple MXML component where this consistently reproduces? Thanks!

[esidegallery]

OK, I set up a fresh install on a Windows 10 Pro x64 VM. The screenshot below shows the configuration. I'm using that version of Java due to issue #507 (perhaps it's been resolved in a subsequent version you're using?)

Anyway, I'm getting the same results with this bare-bones project:
Format Test.zip

[joshtynjala]

I'm using that version of Java due to issue #507 (perhaps it's been resolved in a subsequent version you're using?)

It looks like I'm currently using JDK 11.0.13. I don't know if it has the same issue or not, though.

Anyway, I'm getting the same results with this bare-bones project

Thanks, I'll take look.

[esidegallery]

Hey Josh,

Installed JDK 11.0.13, and also the very latest JDK for good measure. Neither have fixed the issue for me.

[esidegallery]

Another issue I came across with case blocks inside switch statements:

Code before formatting:

Formatter indents case blocks with braces:

I would expect the braces to be treated like the parent switch braces, like the pre-formatted example above.

If I don't use braces, alignment looks correct:

Shall I create an issue for this?

[joshtynjala]

Interestingly, I implemented it this way on purpose. I realized that case doesn't actually have a "body" in the same way that if, for, while, etc. have a body. Adding curly braces inside a case is more like creating a random block in the middle of a function, like this:

function myFunction():String
{
	var s:String = "hi";
	{
		// this is a just a random block, not associated with a conditional or loop
	}
	return s;
}

To put it another way, the following code would be equivalent to your example, and does not change its behavior:

switch(score)
{
	case 0:
		{
			trace("poor");
		}
		break;
	case 1:
		{
			trace("average");
		}
		break;
	case 2:
		{
			trace("good");
		}
		break;
}

You'd expect those blocks to be indented at the same level as the break statement, right? Well, when a case contains only a block, it's getting formatted the same way.

That being said, I could still potentially make an exception for a case that contains only a block. However, I think part of why I settled on not giving it a special case was because implementing it like that would actually require more complexity than any other part of the formatter. Most of the "rules" in the formatter only need to look ahead one or two "tokens", but this would need to look ahead as many tokens as it takes to find the closing curly brace (while keeping track of any new pairs of curly braces in between), plus one or two more tokens, to figure out if another case or default follows, or if a regular statement follows. Not impossible, but non-trivial compared to other stuff the formatter is doing.

This is not to say that I won't do it, but I thought it was pretty interesting how it's not actually a body, so it makes sense, in a way, not to format it like one.

Feel free to open an issue.

[esidegallery]

No, your explanation makes total sense. I never actually used to put case blocks in braces, and not sure why I even started!

I will add an issue for the Windows MXML issue.

This is probably the same thing as my first post, but this definitely feels wrong to me. I guess this would come under the banner of 'nested mixed block indentation' issues?:

[joshtynjala]

I never actually used to put case blocks in braces, and not sure why I even started!

You may have seen me use it in the Feathers source code. :)