-
Notifications
You must be signed in to change notification settings - Fork 234
add Save to FileContext API #590
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -54,6 +54,13 @@ public interface IEditorOperations | |
/// <returns>A Task that can be tracked for completion.</returns> | ||
Task CloseFile(string filePath); | ||
|
||
/// <summary> | ||
/// Causes a file to be saved in the editor. | ||
/// </summary> | ||
/// <param name="filePath">The path of the file to be saved.</param> | ||
/// <returns>A Task that can be tracked for completion.</returns> | ||
Task SaveFile(string filePath); | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would adding to this interface be a breaking change? I know we have at least two new implementations of PSES since this interface was last changed. Should new features be added as additional interfaces, something like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point.. but I think if we were going to make a new interface, I'd want it to be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As far as I know, nobody is using these interfaces outside of PSES itself. Adding a method to an interface wouldn't be a breaking change so I think a new interface shouldn't be necessary for this. |
||
/// <summary> | ||
/// Inserts text into the specified range for the file at the specified path. | ||
/// </summary> | ||
|
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.
If you pass
ClientFilePath
here instead ofFilePath
you should be able to avoid resolving the path when it gets to VSCode. TheInsertText
method is a good example for both sides.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.
@SeeminglyScience + @daviwil: So I tried passing in
ClientFilePath
. It prefaced it withfile://
.This is not ideal because for
openFile
andcloseFile
here:https://github.com/PowerShell/vscode-powershell/blob/master/src/features/ExtensionCommands.ts#L362-L409
We have VSCode already resolving the paths.
So I think we should either continue resolving the paths via VSCode, or modify
openFile
andcloseFile
to expect aClientFilePath
as well. That way, we are consistent.Thoughts?
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.
@tylerl0706 Ah I'd keep it as is then. In general I think it's better to have PSES do the work, but it's probably not worth changing the others.