Skip to content
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

New-EditorFile works on non-powershell untitled files #774

Merged
merged 7 commits into from
Oct 29, 2018

Conversation

TylerLeonhardt
Copy link
Member

@TylerLeonhardt TylerLeonhardt commented Oct 14, 2018

Partnered with: [vscode-powershell issue]

This fixes the problem where $psEditor.GetEditorContext() assumed that the file open was a real file on the file system OR a powershell untitled file. Since that isn't always the case, It would throw an exception:

Exception calling "GetEditorContext" with "0" argument(s): "One or more errors occurred. (Could not find file '/Users/tyler/Code/PowerShell/vscode/PowerShellEditorServices/untitled:Untitled-1'.)"
At /Users/tyler/.vscode-insiders/extensions/ms-vscode.powershell-1.9.0/modules/PowerShellEditorServices/Commands/Public/CmdletInterface.ps1:152 char:13
+             $psEditor.GetEditorContext().CurrentFile.InsertText(($val ...
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : AggregateException

This also means that New-EditorFile -Value 'asdf' actually works when you don't have your default language mode set to PowerShell.

Now we try to get the file and if that throws a FileNotFound, we grab the ScriptFile from the FileBuffer

fixes #434

@@ -101,6 +101,25 @@ public ScriptFile GetFile(string filePath)
return scriptFile;
}

/// <summary>
/// Tries to get an open file in the workspace. Returns true or false if it succeeds.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit - would probably phrase the end of the summary this way "Returns true if it succeeds, false otherwise.".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tylerl0706

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed :)

Copy link
Contributor

@rkeithhill rkeithhill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

@SeeminglyScience SeeminglyScience left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️ this change. One suggestion and one nit

ScriptFile scriptFile = null;
if (!this.editorSession.Workspace.TryGetFile(clientContext.CurrentFilePath, out scriptFile))
{
scriptFile = this.editorSession.Workspace.GetFileBuffer(clientContext.CurrentFilePath, clientContext.CurrentFileContent);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Consider putting each arg on a new line

scriptFile = GetFile(filePath);
return true;
}
catch (FileNotFoundException)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing there are other reasons for failure here, like in:

ScriptFile scriptFile;
try
{
scriptFile = workspace.GetFile(file);
}
catch (Exception e) when (e is IOException
|| e is SecurityException
|| e is FileNotFoundException
|| e is DirectoryNotFoundException
|| e is PathTooLongException
|| e is UnauthorizedAccessException)

It looks like we need to consolidate all our file access into a single internal API.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should leave GetFile(), move this large catch inside TryGetFile(), and reuse TryGetFile() in the LanguageService and DebugAdapter. It looks like the opposite consideration is in GetFile() itself:

if (!this.workspaceFiles.TryGetValue(keyName, out scriptFile))
{
// This method allows FileNotFoundException to bubble up
// if the file isn't found.
using (FileStream fileStream = new FileStream(resolvedFilePath, FileMode.Open, FileAccess.Read))
using (StreamReader streamReader = new StreamReader(fileStream, Encoding.UTF8))
{
scriptFile =
new ScriptFile(
resolvedFilePath,
filePath,
streamReader,
this.powerShellVersion);
this.workspaceFiles.Add(keyName, scriptFile);
}
this.logger.Write(LogLevel.Verbose, "Opened file on disk: " + resolvedFilePath);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to call this out.

We are logging the exception as well in the current implementation. Typically I've not seen TryX functions give access to the underlying exception.

That said, I guess we could add an overload that will let you out the exception as well:

public bool TryGetFile(string filePath, out ScriptFile scriptFile, out Exception exception)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume we don't want to log the exception within the Try_ method? It would contain a full stack trace, but we could log it as a warning, since we used a Try_.

Copy link
Contributor

@rjmholt rjmholt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@TylerLeonhardt
Copy link
Member Author

proof: http://recordit.co/XeLdWL2sjC

@TylerLeonhardt
Copy link
Member Author

oo CI failure on docs that's nice (pls still review as soon as you can because of time change)

@TylerLeonhardt
Copy link
Member Author

Ok this is ready for review

Copy link
Collaborator

@SeeminglyScience SeeminglyScience left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't wait for this :) awesome job! Just one question

Copy link
Contributor

@rjmholt rjmholt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM -- just need to look at @rkeithhill's comment

@rjmholt rjmholt merged commit d85a019 into PowerShell:master Oct 29, 2018
@rjmholt
Copy link
Contributor

rjmholt commented Dec 2, 2018

@TylerLeonhardt TylerLeonhardt deleted the fix-new-editorfile branch September 16, 2019 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

$psEditor.GetEditorContext() doesn't work with untitled-1 unsaved file
4 participants