You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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":
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.
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
enable_bracketed_paste
(EnableBracketedPaste
) anddisable_bracketed_paste
(DisableBracketedPaste
), either to global scope or to the terminal depending on the unix/windows implementation details.Event::Paste
variant that holds the entire pasted stringKeyCode::BracketedPasteStart
andKeyCode::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.Describe alternatives you've considered in any
An alternative is to use something like
rustyline
to handle shell-like input, and only usecrossterm
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":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 liketui-rs
widgets. See this issue for other compatibility issues withrustyline
.Additional context
termwiz
crate has a similar kind ofInputEvent
as solution [1].rustyline
crate has a similar kind ofKeyCode
as solution [2].The text was updated successfully, but these errors were encountered: