-
-
Notifications
You must be signed in to change notification settings - Fork 611
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
[RFC]: add support for bracketed paste in the REPL #2068
Comments
Following up on this, now that the REPL supports auto-closing of paired symbols, the ability to paste expressions into the REPL is broken, as auto-closing attempts to automatically insert paired symbols as the expression's character sequence is written to the output stream. |
@Snehil-Shah What's your opinion on how easy this will be to implement? Atm, attempting to paste multi-line expressions is broken, and it would be nice to, e.g., copy-paste an entire function definition from a file directly into the REPL. |
@kgryte As bracketed paste mode is something terminals support, I think it should be pretty straightforward. We enable bracketed paste. If we receive the escape sequences, we trigger our manual multiline handler till we receive the closing sequence and it's done, but it's all in my head, so I'm not yet aware of the real challenges (if any). And also as you mentioned in OP, we might have to find a way to detect if they already had their terminal in bracketed paste mode. |
TMK there isn't a clear way to test or detect if bracketed-paste mode is enabled or not in the terminal. Bracketed paste is supported by the 'terminal' application and so I don't think we can access or even simulate pasting content onto the terminal to test the existing status of bracketed-paste mode. Here is how other REPLs do it:
|
I wonder if we could detect by silently testing whether bracketed paste works by attempting to paste and checking against expected output. I would imagine that the REPL should behave one way if bracketed paste is enabled and another if disabled. Maybe we could rely on heuristics? |
That's the thing, I don't think there is a way to simulate the action of pasting into the terminal if that's what you are suggesting.. |
Yeah, that was what I was wondering. Hmm. Okay, maybe we should have a setting which a user can set to explicitly enable/disable bracketed paste.
|
I think it would be better if we don't have a default for this setting as we don't want to automatically/magically mess with their terminal's global state unless they specifically want it to? Although python 3.13 REPL does enable it by default judging from their code and the test I linked above. |
My sense is that it is preferable that things just work out of the box. In which case, at least in TTY, we should enable by default. A user can explicitly opt-out during instantiation. We still need to add CLI configurability, but this can be addressed when we add CLI option support for other REPL settings. |
Description
This RFC proposes adding support for bracketed paste in the REPL. Currently, if you were to copy
into the REPL, you'd get
where, if the pasted content contains a newline character, the expressions will be automatically evaluated.
The idea behind bracketed paste is to recognize pasted content so that a user can inspect and potentially edit pasted content before explicitly executing.
Enabling bracketed paste should be a matter of using escape sequences and then checking for a paste start sequence before executing content and then waiting for the paste to stop by checking for the stop sequence.
Once the REPL exits, we should disable bracketed paste.
Additionally, we should add an option which can be set during REPL instantiation (via the REPL constructor) for enabling/disabling bracketed paste, with the default behavior being enabled.
Related Issues
Questions
Other
Checklist
RFC:
.The text was updated successfully, but these errors were encountered: