-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Allow execute on enter and Intellisense for native REPL with notebook UI #23442
Conversation
package.json
Outdated
{ | ||
"command": "python.execInREPLEnter", | ||
"key": "enter", | ||
"when": "activeEditor == 'workbench.editor.interactive'" |
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.
should I also be adding !config.interactiveWindow.executeWithShiftEnter
here in the when clause? @amunger
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.
yes please
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.
For some reason, adding this when clause in makes the whole command get ignored when user presses enter. (I have not personally set up any shift enter keybinding override on my machine).
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.
Found why it is not working..(As in figured out why after adding !config.interactiveWindow.executeWithShiftEnter to when clause would not let user execute with enter by default. Basically user has to have explicit "interactiveWindow.executeWithShiftEnter": false,
in their settings.json.
Value for "interactiveWindow.executeWithShiftEnter" seems to be true by default, but Python extension would ideally want the default to be false. Should Python extension somehow override the value of this?
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 was planning to switch the default, but I didn't get around to putting in the migration logic for jupyter IW users. So you should be able to leave it as is for now (and manually set the setting), and I'll still try to make the switch
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.
@amunger When you say "leave it as is for now" and update the setting, do you still want the !config.interactiveWindow.executeWithShiftEnter
clauses in the "when" condition, and also have Python extension manually set the "interactiveWindow.executeWithShiftEnter": false,
for users?
OR
just exclude using !config.interactiveWindow.executeWithShiftEnter
in when clause
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.
We still need the when
clause here, otherwise users who want to use shift+enter to execute will not be able to use enter for a newline.
By manually, I meant users will individually need to change that setting until the default is switched over, don't change anyone's configuration since we were planning on doing that in the other direction for jupyter IW users.
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.
got it, it should be resolved with: 910783b
Co-authored-by: Courtney Webster <60238438+cwebster-99@users.noreply.github.com>
@@ -628,6 +628,12 @@ | |||
"scope": "resource", | |||
"type": "boolean" | |||
}, | |||
"python.REPL.sendToNativeREPL": { |
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.
This does not have the experimental tag?
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.
Right, this is the settings which the value is ultimately overridden by the experiment value "pythonRunREPL".
Initially thought everything was just going to be experiment, but got convoluted with going the settings based experiment route
Following:
We also should get rid of the experiment item that we added for this, as the setting itself can be controlled via experiment by using the settings tag.
I think I would need to replace of existing "pythonRunREPL" from just experiment to settings (basically replace the setting tag from sendToNativeREPL
to pythonRunREPL
). Would that allow us to leave the control tower as is? @cwebster-99
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 it would be the fully require name python.REPL.sendToNativeREPL
.
We also should get rid of the experiment item that we added for this, as the setting itself can be controlled via experiment by using the settings tag. |
Co-authored-by: Karthik Nadig <kanadig@microsoft.com>
Co-authored-by: Karthik Nadig <kanadig@microsoft.com>
Co-authored-by: Karthik Nadig <kanadig@microsoft.com>
Co-authored-by: Karthik Nadig <kanadig@microsoft.com>
I think I addressed all the requested changes. I will put up additional PR to better refactor this. |
src/client/repl/replCommands.ts
Outdated
} | ||
}), | ||
); | ||
} | ||
|
||
export async function registerReplExecuteOnShiftEnter(): Promise<void> { | ||
commands.registerCommand(Commands.Exec_In_REPL_Shift_Enter, async () => { |
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.
This needs a disposable, similar to other commands registered.
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.
Should be good with: e270705
… UI (#23442) "Smartly" allow execute on enter for the #23235 experiment. User should be able to execute when they press enter on text input box of interactive window trigger from Python extension, whereas we would "wait" and allow insertion of new line after detecting user's Python command is not complete. When the user finally types enter again on a blank line, we should just proceed to execute whatever code, regardless of whether it is complete/valid or not to replicate Python's original interactive REPL behavior. Basically creating Python command and registering that for keybinding of 'Enter'. This would conditionally call interactive.execute which would then eventually call our execute handler contributed from Python n extension's REPL controller, or go ahead and insert,pass in Enter to the text input box to allow user to type "complete" code. This PR only intends to implement/add changes regarding execute on enter logic, adding Intellisense support, and also adding things into disposables so they can be properly disposed. Trying to also add setting to allow toggling on/off to send Python command to Terminal or IW REPL if the user is in experiment. Handling of interrupt for windows should be on separate PR. Test will be added later as separate PR. --------- Co-authored-by: Courtney Webster <60238438+cwebster-99@users.noreply.github.com> Co-authored-by: Karthik Nadig <kanadig@microsoft.com>
"Smartly" allow execute on enter for the #23235 experiment.
User should be able to execute when they press enter on text input box of interactive window trigger from Python extension, whereas we would "wait" and allow insertion of new line after detecting user's Python command is not complete.
When the user finally types enter again on a blank line, we should just proceed to execute whatever code, regardless of whether it is complete/valid or not to replicate Python's original interactive REPL behavior.
Basically creating Python command and registering that for keybinding of 'Enter'.
This would conditionally call interactive.execute which would then eventually call our execute handler contributed from Python n extension's REPL controller, or go ahead and insert,pass in Enter to the text input box to allow user to type "complete" code.
This PR only intends to implement/add changes regarding execute on enter logic, adding Intellisense support, and also adding things into disposables so they can be properly disposed. Trying to also add setting to allow toggling on/off to send Python command to Terminal or IW REPL if the user is in experiment.
Handling of interrupt for windows should be on separate PR.
Test will be added later as separate PR.