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

Fix edit when command is set to Visual Studio code #31864

Merged
merged 1 commit into from
May 6, 2019

Conversation

musm
Copy link
Contributor

@musm musm commented Apr 29, 2019

By default VS Code adds code.cmd to path. Thus simply setting the JULIA_EDITOR=code (the obvious thing) will fail since julia, without knowing it is a cmd, assumes it is an exe. The logic here is thus special cased.

I decided to refrain from making this change in this PR (see the last comment)

This fixes the incorrect fall through in the scenario where the user sets JULIA_EDITOR=code.cmd, since name == "code" || (Sys.iswindows() && uppercase(name) == "CODE.EXE") does not capture this case, which prevents line information passing through.

JULIA_EDITOR=code.cmd, should work since code.cmd is added to path by VS Code.

@musm
Copy link
Contributor Author

musm commented Apr 29, 2019

cc @davidanthoff

@davidanthoff
Copy link
Contributor

I assume this is in relation to this line, correct?

@musm
Copy link
Contributor Author

musm commented Apr 29, 2019

This change was actually independent of the vs-code plugin and discovered from trying to set vscode as the REPL editor. I pinged you since you are familiar with vscode and thus would be an appropriate reviewer.

For the change you linked to, what does process.execPath point to? If it points to the exe then it will work and this PR does not touch that.

This PR fixes the case when you set JULIA_EDITOR=code (MSFT automatically adds code.cmd) to path, which right now does not work. It also fixes the case when you link to C:\Program Files\Microsoft VS Code\bin\code.cmd. If you set it to C:\Program Files\Microsoft VS Code\Code.exe it will work and this PR does not affect this scenario.

@davidanthoff
Copy link
Contributor

process.execPath points to the exe, so that should be all good pre and post this PR, right?

So yes, then this PR looks good to me :)

@musm
Copy link
Contributor Author

musm commented Apr 29, 2019

process.execPath points to the exe, so that should be all good pre and post this PR, right?

Yes, that case is unaffected. This PR expands the scope to be more lenient.

@musm
Copy link
Contributor Author

musm commented May 2, 2019

squashed and good to go on my end

By default VS Code adds `code.cmd` to path. Allow `code.cmd` within the vs code chain.
@musm
Copy link
Contributor Author

musm commented May 2, 2019

I should clarify that I decided to make this the most minimal change after thinking about various cases more carefully.

The behavior before the squash was more permissive, but I think the minimal change just pushed is OK overall and improves the situation.

@musm
Copy link
Contributor Author

musm commented May 5, 2019

this is good to merge

@StefanKarpinski
Copy link
Member

Anyone use VS Code and want to try this and then merge it, assuming it works?

@KristofferC KristofferC merged commit bdffb56 into JuliaLang:master May 6, 2019
@musm musm deleted the patch-13 branch May 6, 2019 15:25
@musm
Copy link
Contributor Author

musm commented May 6, 2019

Could we add this to backport?

@KristofferC
Copy link
Member

KristofferC commented May 6, 2019

Feature freeze was long ago so not really.

@musm
Copy link
Contributor Author

musm commented May 6, 2019

Makes sense. I'm not sure the procedure for backporting PRs, but for the next release including this PR would be appreciated.

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.

4 participants