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

Bracketed Paste Events #545

Closed
bhgomes opened this issue Mar 11, 2021 · 1 comment
Closed

Bracketed Paste Events #545

bhgomes opened this issue Mar 11, 2021 · 1 comment

Comments

@bhgomes
Copy link

bhgomes commented Mar 11, 2021

Is your feature request related to a problem? Please describe.
I want to be able to process input that contains line feeds. Allowing the terminal to enter bracketed paste mode allows us to buffer an incoming paste and collect non-Enter line feeds. This is already a standard feature of many terminal emulators.

Describe the solution you'd like

  • Add the relevant enable/disable pair: enable_bracketed_paste (EnableBracketedPaste) and disable_bracketed_paste (DisableBracketedPaste), either to global scope or to the terminal depending on the unix/windows implementation details.
  • Here are a few options for formatting the paste:
    • [1] Add Event::Paste variant that holds the entire pasted string
    • [2] Add KeyCode::BracketedPasteStart and KeyCode::BracketedPasteEnd variants and allow the user to access escape codes so that they can implement paste filtering themselves (not very user-friendly) or another part of this library will do the paste filtering.
  • Because both of these options change the enum interfaces, we can probably put this behind an optional feature.

Describe alternatives you've considered in any
An alternative is to use something like rustyline to handle shell-like input, and only use crossterm to handle other kinds of interaction. The problem with something like [rustyline] is that it only allows stdin/stdout as far as I am aware and won't be able to implement something like the following "half-shell":

-----------------------------
|             |             |
|  [shell     |             |
|  output]    |   [other    |
|             |   widget]   |
|-------------|             |
| > [prompt]  |             |
-----------------------------

where the [other widget] can read arrow key and other non-text inputs (i.e. how is [rustyline] supposed to know that the input should wrap only at half the terminal width?). Also, multi-panel input components like tui-rs widgets. See this issue for other compatibility issues with rustyline.

Additional context

@TimonPost
Copy link
Member

Fixed by: #693

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

No branches or pull requests

2 participants