Consider adding KeyEvent::Enter

[MonsieurMan]

Hello !

Just began using the library and I searched for more than 5 minutes if I was having a bug with Enter not being present in the enum.

// Pressing Enter in terminal apps is pretty recurrent, so I really think
// this is easier to use and read
KeyEvent::Enter
// Than this
KeyEvent::Char('\n')

I can send a PR if you're interested

[zrzka]

I have to say that I like the idea. But this brings my attention:

https://github.com/TimonPost/crossterm/blob/91d07275adbb15e5aab15df52d7f51808faa57dd/crossterm_input/src/input/unix_input.rs#L269

 ~ echo -e "foo\nbar"
foo
bar
 ~ echo -e "foo\nbar" | hexdump 
0000000 66 6f 6f 0a 62 61 72 0a                        
0000008
 ~ echo -e "foo\nbar" | unix2dos
foo
bar
 ~ echo -e "foo\nbar" | unix2dos | hexdump 
0000000 66 6f 6f 0d 0a 62 61 72 0d 0a                  
000000a
 ~ 

Shouldn't we ignore \r on #[cfg(unix)]? \r means nothing on UNIX. IIRC it was used on the old Macs (pre OS X, long time ago). Mentioning it here, because it's on the same line :)

[MonsieurMan]

I'd say it's on the... next line ! 😁 The code you linked is kind of lying to users. The library tells \n has been sent when it could actually be \r, so a Enter KeyEvent would definitely be valuable. What is the behavior then, windows platform always send \r and Linux&Mac always send \r ? As for using the #[cfg(Unix)] I'm not rusty enough to know how it works and what are the consequences, I'll look into that tomorrow :) Le mer. 18 sept. 2019 à 11:29 PM, Zrzka <notifications@github.com> a écrit :

…

I have to say that I like the idea. But this brings my attention: https://github.com/TimonPost/crossterm/blob/91d07275adbb15e5aab15df52d7f51808faa57dd/crossterm_input/src/input/unix_input.rs#L269 ~ echo -e "foo\nbar" foo bar ~ echo -e "foo\nbar" | hexdump 0000000 66 6f 6f 0a 62 61 72 0a 0000008 ~ echo -e "foo\nbar" | unix2dos foo bar ~ echo -e "foo\nbar" | unix2dos | hexdump 0000000 66 6f 6f 0d 0a 62 61 72 0d 0a 000000a ~ Shouldn't we ignore \r on #[cfg(unix)]? \r means nothing on UNIX. IIRC it was used on the old Macs (pre OS X, long time ago). Mentioning it here, because it's on the same line :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#234>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADEAHRTOYTNICJRTYKD24SLQKKMSRANCNFSM4IYDOEIA> .

[zrzka]

There're two implementations.

#[cfg(unix)]

https://github.com/TimonPost/crossterm/blob/91d07275adbb15e5aab15df52d7f51808faa57dd/crossterm_input/src/input/unix_input.rs#L269

#[cfg(windows)]

https://github.com/TimonPost/crossterm/blob/91d07275adbb15e5aab15df52d7f51808faa57dd/crossterm_input/src/input/windows_input.rs#L294

I'd say that the best solution will be to introduce KeyEvent::Enter, return it on these two lines and trash the | b'\r' in the UNIX implementation.

[MonsieurMan]

Just sent a PR, thanks for the guidance !

The hardest part has been generating a new GPG key because I typed the wrong password into my password manager apparently, haha.

[TimonPost]

We probably want to the same with tab which is /t now

[TimonPost]

The main reason why we used /n is that the user could just print all characters received from the input reader to the terminal. In raw modes all terminal actions are disabled as well are the new lines unless explicit written to the screen. By returning /n or /t the user could still read special events while his input is not affected by the enabled raw mode. Although I do prefer explicitly because I was confused my self with /n /t as well a few times.