Add bracketed paste parsing

[groves]

This is another attempt at adding bracketed paste parsing, like #557. This version keeps from removing the Copy trait on Event and does all of the paste parsing in parse_event, so I'm hoping we can get it to an acceptable state.

Since pasting needs to read in a variable length string, I couldn't find a way to stuff the result in Event since it has Copy. Instead I've added an input module with its own read function. That read returns an Input enum that either contains Event or the pasted data. What I was thinking is that you'd use the input module if you wanted to parse terminal input that included variable length data, or you could keep using the event module if you only need the fixed length events. I didn't want to break all existing API clients and I wanted to let people pass around Events on the stack, and this was the best compromise I came up with.

I need to document this and give it a spin in Helix. I wanted to get some feedback on the approach before polishing it up though.

[TimonPost]

In the past, we thought about why we call something an input or an event. We concluded that events are more general and include input, resize events and more. In this scenario, an input contains an event, but is the resize event an input?

[TimonPost]

I prefer to stick with one read call and one poll function and the Event rather than Input as a top-level structure that is passed to the user. Mixing input and events can be confusing for our users.

[TimonPost]

I wonder if it is really a 'priority' to keep 'copy'. Maybe the users of this library should answer this. I will ask in the discord.

[groves]

I prefer to stick with one read call and one poll function and the Event rather than Input as a top-level structure that is passed to the user. Mixing input and events can be confusing for our users.

Same here. I'm only introducing this weird structure to keep API compatibility.

I wonder if it is really a 'priority' to keep 'copy'. Maybe the users of this library should answer this. I will ask in the discord.

At least in Helix we're passing Events on the stack all over the place. I tried doing this with Copy removed and it made for a pretty massive change in Helix.

I can make that change for Helix, but I didn't want to force it on all other library users. Thanks for asking!

[sigmaSd]

I also vote for just breaking the api because:

• crossterm is still not 1.0, I think we should use this opportunity to keep iterating on the api
• the api introduced here would make crossterm very confusing to new users (should I use read from event module or input module , what is the difference)

[TimonPost]

Indeed. It is a bit unfortunate if we have to require .clone() calls. Wonder if there is another way that doesn't duplicate the API and doesn't require the removal of Copy

[TimonPost]

I think we can have ´Copy´ by default:

´´´
#[cfg_attr(not(feature= "bracketed-paste", derive(Copy))]
#[derive(Debug, PartialOrd, PartialEq, Eq, Clone, Hash)]
pub enum Event { }
´´´

This way copy is always enabled unless you use the bracketed paste feature flag.

Also

´´´
#[cfg(not(feature = "event-copy"))]
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub struct EnableBracketedPaste;
´´´

can be

´´´
#[cfg(feature = "bracketed-paste")]
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub struct EnableBracketedPaste;
´´´

So think we can just remove event-copy

[lnicola]

#[cfg_attr(not(feature= "bracketed-paste", derive(Copy))]

Features are supposed to be additive, so enabling a feature shouldn't cause an impl to disappear.

[TimonPost]

Yes indeed, it is a bit of a draw back with this method. We have to pick: Remove copy resulting in us having to call .clone() everywere which is annoying. Dont add this feature. Or change the entire API. Or do a mix and just add it as feature flag and mis use feature flags which is not ideal but has a bit of both sides.

[lnicola]

Do most of the crossterm users (besides Helix) copy Events that much?

[sigmaSd]

I think the new cfg bracked-paste is a nice idea, those who wants to keep the old clone trait can just opt out of it.

That will certainly make the breaking change easier.

[groves]

Sorry for the noise from all the half-complete pushes on this PR. I was getting it to run the Windows tests for me. I should be done with changes now.

I was thinking we could make a release with this bracketed-paste feature flag in place with a note in the changelog that it'll be removed in a future release. Since it's on by default, that'll get other people using Copy to notice the compilation breakage. They can turn off bracketed-paste to get compilation going immediately, and then remove or rework the use of Copy at their leisure.

It's still an obnoxious change, but hopefully that makes it less obnoxious.

[TimonPost]

That sounds also good to me.

[TimonPost]

Looks good now! Thanks