Added a small set of reasonable trait implementations (Debug, Copy, Clone, PartialEq, and Eq) to all of the commands. The largest command is a pair of u16, so they're easily copyable.

When using the Command API and the alternate screen, I'd like to only use stderr for all displays in order to precisely decide what I write on stdout.

It looks like it's almost possible but there are still some chars written on stdout even if I only queue on stderr.

I suspect this is related to the few places where there are calls to write_cout without the first argument.

Could we fix this ? Is it already in process ?

It's possible a few API would have to change, for example for the alternate screen.

I'm on Windows 10 and running my app in PowerShell console.

My app reacts to Enter key (char 13), and it triggers the reaction immediately after the start. I tracked down the problem to the fact that it's processing the Enter key that I was using to invoke the command from the cli.

I.e.:

1. I type .\target\debug\myapp.exe
2. I press "Enter" key.
3. My app starts and immediately triggers "Enter" key handler (cauisng it to quit in my case).

I expect step 3 to be "My app starts and waits for input".

I tried both sync and async input - the behaviour is the same.

I'm using fixes branch.

• Platform: macOS
• It works when I replace input.read_async(); with input.read_sync();
• Run, click with the mouse and ...

examples/foo.rs:

use crossterm_input::{InputEvent, KeyEvent, MouseEvent, RawScreen, Result, TerminalInput};

fn main() -> Result<()> {
    let input = TerminalInput::new();
    let _raw = RawScreen::into_raw_mode()?;

    let mut reader = input.read_async();
    input.enable_mouse_mode()?;

    loop {
        if let Some(event) = reader.next() {
            match event {
                InputEvent::Keyboard(KeyEvent::Esc) => break,
                InputEvent::Keyboard(KeyEvent::Enter) => println!("Enter"),
                InputEvent::Mouse(mouse) => {
                    match mouse {
                        MouseEvent::Press(_, x, y) => println!("Press: {}x{}", x, y),
                        MouseEvent::Hold(x, y) => println!("Move: {}x{}", x, y),
                        MouseEvent::Release(x, y) => println!("Release: {}x{}", x, y),
                        _ => {}
                    };
                }
                _ => {}
            };
        }
    }

    input.disable_mouse_mode()?;
    Ok(())
}

In Reedline we are experimenting with having a secondary prompt on the right to present information to the user. This is an example of how it looks now

However, if the prompt in the left ends with a newline, everything after the prompt flickers. Like this

Is there any recommendations that you have to avoid this type of flickering?

Hi all,

We use crossterm in nushell in a few different places, and have generally been pretty happy with it. Recently, I tried to update from 0.10.x to 0.12.x. While the API changes were easy to fix, the result was a system that no longer worked.

Does someone have a minute to look over https://github.com/nushell/nushell/blob/master/src/fuzzysearch.rs and let me know why it doesn't work in 0.12.x (ignoring the slight API differences)

Here are some of the issues we see with 0.12.x when we try it:

• Hitting enter on a selection doesn't work
• After fuzzy search runs, input is eaten about every other character, so you can't type in the nushell prompt correctly anymore

This is a tracking issue for the work what still needs to be done for reading input.

• [X] Reading Keys Presses This feature should porovide support for the following Key Events - winapi example code. - Special key combinations
• [X] Mouse Events (example) - Allow to capture mouse down, up and hold events. - Allow seeing which mouse button is pressed.
• [X] cleaning up old threads
• [x] Testing

The documentation of TerminalInput states for TerminalInput::read_sync:

Readings will be blocking calls.

On windows this will resolve in call to ReadConsoleInput and according to MSDN it blocks.

The function does not return until at least one input record has been read.

But there is a problematic fast return, causing ReadConsoleInput not to be called.

https://github.com/TimonPost/crossterm/blob/8223cc9e4a5e35e15a0287bd9d8aa53dc84d1c34/crossterm_winapi/src/console.rs#L170-L173

Also some events return None, even though further events can be received:

https://github.com/TimonPost/crossterm/blob/8223cc9e4a5e35e15a0287bd9d8aa53dc84d1c34/crossterm_input/src/input/windows_input.rs#L230-L233

While this is valid behaviour for iterators, this causes early returns when iterating with for or while. This should be either changed or documented.

Task Description

Crossterm flushes the buffer each time action with an ANSI-code is performed. This is not realistic in the case of moving the cursor a lot and meanwhile print characters. When calling those types of functions a lot, cross-term might behave a bit slow.

• Flushing is done here
• Locking on stdout is done as well on each ANSI write to the terminal, however, flushing is way more performance bottleneck then the lock.

Task TODO

• [ ] Research if it is possible to let the user control the flushing so that the user can control when to flush the ANSI-commands to the terminal. Issue #167 can be related to this issue. More explanation about this in the comments.
• [ ] If we found out a way to make ANSI-codes more performant, we are left with one problem. WINAPI. The nice think about ANSI codes is that you can queue them up somewhere and push them into the stdout later on. With WinApi the user interacts directly with the terminal, and you can't queue them in the same way of ANSI-codes.

Example of what I mean:

winapi scenario of moving the cursor

Move cursor (10.10)
println!("abc");
Move cursor (10,10)

ansi scenario to move the cursor

println!("\x1B[{10};{10}H abc \x1B[{5};{5}H");

As you can see, in the case of ANSI codes we can store the codes and text of the user inside on string, however, with WinApi we don't store actions inside a string. But those are calls that need to be made to the console individually.

Somehow, we need to be able to store those WinApi commands in order ass well. So that if the user does a manual flush to the terminal, in the case of windows, we walk through all the WinApi commands queued and execute those, as well print the user input, done between those two cursor move events.

Notice

I do notice, Linux is way faster with console actions than windows is. I am not sure whether this is the problem of rust using winapi to write to the console window, winapi ANSI interpretation layer, crossterm performance issue. Windows is often forgotten in the Rust library, and would not be amazed if there is some performance issue there somewhere. But this needs to be proven of course.

Description

• There was a dead lock in the EventStream::drop implementation (thanks for the discovery @udoprog!)

Changes

• Introduced Waker which kind of mimicks upcoming mio (0.7) Waker
  • Allows us to remove self pipe trick, etc. and do it via Evented on UNIX
  • Waker is clonable, shareable, sendable, ...
• Implemented for both Windows & UNIX

Tests

• Tested on UNIX only

Alternative

This is an alternative to the #328 PR.

What's better?

• No public reexports of CancelRx, ...
• No warnings for unused imports, dead code, ...
• Completely hidden and not visible in the internal API until event-stream is enabled

What's worse?

• Not sure if it's a good idea to hide it in this way = removing it from the poll_internal argument

Note, this design is not accurate anymore. Please have a look further into the discussion.

New

• Introduced the things discussed here. It already addresses some of your comments. There is still some work left for this to be finished. I would like to hear your ideas on how to future envolve this?
• Removes Terminalnput because it would become boilerplate code.
• Introduces: ~EventChannel~, ~EventConsumer~, EventPool, ~EventIterator~, EventSource.
• ~Allows iterating specific events.~
• Allows swapping out event source (testing)
• ~Introduces a single producer multiple consumer idea for input sharing~

usage example

use crossterm::{event_stream, poll_event, RawScreen};

fn main () {
    let r = RawScreen::into_raw_mode().unwrap();

    let mut stream = event_stream();

    while true {
        poll_event();

        for event in stream.key_events() {
            println!("{:?}", event);
        }
    }
}

~## Area of Discussion:~

~- Should we store local cache in EventStream? The idea behind this is that when reading from the channel we drain the events at the same time? When we read we can store them locally so that we can consume them later on and no events will be lost when for example the user uses InputStream::key_events first and then InputStream::events().~ ~- Should the poll function only read a single event or read everything available in the buffers.~

~## Todo~

• [ ] implement mouse event enable/disable
• [ ] implement read line
• [ ] More tests
• [ ] Documentation

~## Diagram:~

Definitions

SPMC

~I use shrev EventChannel for this, this channel can have multiple readers and a single writer. This is exactly what we want. I tried with normal MPMC channels before, but this didn't work out well. It required a lot of manual thread-safe work like putting everything in arc, mutexes, etc.~

Event Pool

EventPool

• It is stored statically in with lazy static, there should only be one instance of this pool. ~- It is the owner of the SPMC channel.~
• It is the only one allowed to grant read/write access to the owned event channel. ~- It can create multiple consumers and a single producer. ~
• Access to EventPool is secured with RwLock. Therefore consumers can be created while a write lock is obtained. ~- Behaves similar to Stdin~
• Only reads a single input event on poll. This allows the user to create its own async wrapper. The

~EventPoolReadLock~

~- Provides read access to the EventPool~

EventPoolWriteLock

• Provides write access to EventPool

~event_stream~

~-A static function that returns an event stream that can be used to read input events with.~

poll_event

~A static function that polls for input from the underlying input source. An input event will be replicated to all consumers aka streams if an input event has occurred. This poll function will block read for a single keypress.~

Input Source

InputPool has one input source. This input source can be anything. In the tests I use the FakeInputSource, this allows us to fake input data, this might be useful for the user as well for testing it's application.

• An input source does a block read for one key event.
• Input source is called by InputPool::poll()

The PR contains three input sources: TtyEventSource, WinApiEventSource, FakeEventSource

~### Event Stream~

~- Has it's own SPMC consumer, can't write, only read.~ ~- It can iterate specifically over certain events, like a mouse, keyboard. This is a great feature I like to support. Because most often people only want to read for up, down, left, right arrows for example.~

as the title says, trying to use bracketed paste on windows , just yields a series of Event::char

This works on termwiz though, so its probably something missing we can copy over

Dince mio doesn't handle ptys correctly macOS, use filedescriptor's poll() which falls back to select().

This PR replaces #711.

Fixes #500, unblocks #407.

Implementation notes

Since poll() doesn't support waking from signals or otherwise, I create two unix socket pairs, one which is written to on SIGWINCH and one which is used by the Waker, and poll on those as well as the tty fd.

Suppose I have the following function:

fn render_1 <W: Write> (out: &mut W) -> Result<()> {
  queue!(out, MoveTo(2, 3), Print("foo"))
}

I want to remove the generic W and replace it with a trait object using dyn.

fn render_2 (out: &mut dyn Write) -> Result<()> {
  queue!(out, MoveTo(2, 3), Print("foo"))
}

The latter form fails with the following error:

error: the `by_ref` method cannot be invoked on a trait object
  --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/crossterm-0.25.0/src/macros.rs:63:20
   |
58 |   macro_rules! queue {
   |   ------------------ in this expansion of `queue!`
...
63 |           Ok($writer.by_ref())
   |                      ^^^^^^
   |
  ::: crates/common/lib_tui.rs:32:5
   |
32 | /     queue!(out,
33 | |         ResetColor,
34 | |         SetForegroundColor(bg),
35 | |         MoveTo(col1, row1),
36 | |         Print("▄".repeat(cols as usize)),
37 | |         ResetColor, SetBackgroundColor(bg)
38 | |     )?;
   | |_____- in this macro invocation
   |
   = note: you need `&mut dyn std::io::Write` instead of `&dyn std::io::Write`

I can't completely wrap my head around Write::by_ref or its usage in the queue! macro. The comment says This allows the macro to take both mut impl Write and &mut impl Write. This looks like it's breaking dynamic dispatch entirely, for the sake of saving a & token? Can someone please explain?

What I want to achieve is define a trait Widget which supports dyn (i.e. has no generic methods of its own); for this, its render method must be like render_2 and not like render_1.

This follows the Kitty documentation's recommended way to check for progressive keyboard enhancement: query the flags and then query the primary device attributes (which is broadly supported). If we receive the response to the flags query, we return the flags. Otherwise, the terminal must not support progressive keyboard enhancement.

Closes #717

Is your feature request related to a problem? Please describe. There is no command for ringing the terminal bell, at least not from what I can find.

Describe the solution you'd like I would like to see a queue-able and executable command added that rings the terminal bell.

Describe alternatives you've considered in any I could ring the terminal bell manually by printing the relevant escape code, but isn't that what crossterm tries to avoid?

Additional context https://en.wikipedia.org/wiki/Bell_character

Is your feature request related to a problem? Please describe. I have an issue where my program uses a piped stdin, I want to manually open tty as a file and give that to crossterm for event handling though it does not seem possible at the moment. I also tried overriding stdin with the stdio_override crate which also did not work.

To clarify my use case - this was so that I could perform automated integration testing of my event handling implementation

Describe the solution you'd like To be able to specify an input source for event::read and event::poll. Or a global override for the source of events.

Not sure if this is possible. Haven't had the chance to dive deep into the crossterm code yet.