-
Notifications
You must be signed in to change notification settings - Fork 514
Add feature to format PowerShell source files #426
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Really happy to have this feature now! I think we need to take a slightly different approach with the client/server protocol for this to align with the Language Server Protocol since they've already specified the message types for document and range formatting. I'm happy to chat about it tomorrow at the office if you have questions. |
@@ -270,6 +270,21 @@ | |||
"type": "boolean", | |||
"default": false, | |||
"description": "Launches the language service with the /waitForDebugger flag to force it to wait for a .NET debugger to attach before proceeding." | |||
}, | |||
"powershell.codeformatting.openBraceOnSameLine":{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be nice if codeformatting
was cased as codeFormatting
, but it's not a big deal if you don't feel like changing it right now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed!
@@ -0,0 +1,277 @@ | |||
import vscode = require('vscode'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't forget the copyright header
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed.
"PSUseConsistentIndentation"]; | ||
|
||
// Allows edits to be undone and redone is a single step. | ||
// Should we expose this through settings? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, I'd say that the formatting operation should always be treated as one atomic edit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed.
document: TextDocument, | ||
range: Range, | ||
options: FormattingOptions, | ||
index: number): Thenable<TextEdit[]> | TextEdit[] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we could simplify this code a lot by using the TextEdit class as the means for transporting the formatting edits back and forth between extension and server. Check out VS Code's TextEdit class compared to the one we have in the Protocol assembly, they are exactly the same.
I'd recommend pushing as much of this logic to the service side as you can and only sending back the valid TextEdits from the server which will be applied by the client. In fact, I think we should implement this based on the exact protocol messages that are coming in the Language Server Protocol 3.0 since we'll be snapping to that pretty soon anyway. Check these out:
The request type is fairly similar to yours now and the response type is simply an array of TextEdit
. Implementing it this way will future-proof us a lot better.
Kapil and I discussed the protocol changes I asked for, we're going to wait until the next extension update for that work. I'll merge this PR and the one on PSES after the PSScriptAnalyzer PR gets merged. |
Great work! I'll play around with this a bit later today. |
Related PRs: