termion issues
https://gitlab.redox-os.org/redox-os/termion/-/issues
2019-11-01T15:07:56Z
https://gitlab.redox-os.org/redox-os/termion/-/issues/174
Key::Backspace only recognizes 0x7f while Ctrl('h') and 0x08 also represent b...
2019-11-01T15:07:56Z
Allen-Webb
Key::Backspace only recognizes 0x7f while Ctrl('h') and 0x08 also represent backspace.
Just as the title says: Key::Backspace only recognizes 0x7f while Ctrl('h') and 0x08 also represent backspace.
I ran into this problem implementing a shell using termion and was surprised in testing when backspace wasn't working for som...
Just as the title says: Key::Backspace only recognizes 0x7f while Ctrl('h') and 0x08 also represent backspace.
I ran into this problem implementing a shell using termion and was surprised in testing when backspace wasn't working for some of the test cases.
https://gitlab.redox-os.org/redox-os/termion/-/issues/173
Getting cursor position still panics
2021-09-19T21:10:25Z
doums
Getting cursor position still panics
Hi!
I would like to report an old but **big** issue of Termion that still exists:
`cursor_pos()` panics when using stdin in other thread that the one of the call.
The following two examples demonstrate the problem:
Using thread:
```
us...
Hi!
I would like to report an old but **big** issue of Termion that still exists:
`cursor_pos()` panics when using stdin in other thread that the one of the call.
The following two examples demonstrate the problem:
Using thread:
```
use std::io;
use std::thread;
use termion::cursor::DetectCursorPos;
use termion::input::TermRead;
use termion::raw::IntoRawMode;
fn main() {
let mut stdout = io::stdout().into_raw_mode().unwrap();
let handle = thread::spawn(|| {
let stdin = io::stdin();
for _input in stdin.keys() {}
});
let (init_a, init_b) = stdout.cursor_pos().unwrap(); //panics !
println!("{}:{}", init_a, init_b);
handle.join().unwrap();
}
```
Using `async_stdin()`
```
use std::io::{self, Read};
use termion::async_stdin;
use termion::cursor::DetectCursorPos;
use termion::raw::IntoRawMode;
fn main() {
let mut stdout = io::stdout().into_raw_mode().unwrap();
let mut stdin = async_stdin().bytes();
let (init_a, init_b) = stdout.cursor_pos().unwrap(); //panics !
println!("{}:{}", init_a, init_b);
}
```
What does that mean ?
Its means that it is actually impossible to retrieve the cursor position when using `async_stdin` or when stdin is used in another thread.
But using stdin in another thread is the only way to handle input events without blocking the current thread, so it is simply a **huge** use case !
Actually I can not believe that a library like Termion has this kind of problem! I mean, this issue greatly limits the usages of the library.
https://gitlab.redox-os.org/redox-os/termion/-/issues/172
Better UTF-8 support
2019-09-22T00:57:37Z
madprops
Better UTF-8 support
I've been messing with this for hours.
I'm making an input with better support like left/right arrow and home/end, backspace, insert-text-in-the-middle, support (if there's already a solution for this I'd like to know).
Problem is when i...
I've been messing with this for hours.
I'm making an input with better support like left/right arrow and home/end, backspace, insert-text-in-the-middle, support (if there's already a solution for this I'd like to know).
Problem is when inserting and dealing with changes, when a multi-byte utf-8 character is in the text, like 😊 for instance, I get into problems because each cursor position doesn't take into account the whole character, for example the cursor can get placed in the middle of it. Would be nice if cursor movement took into account these multi-byte characters. I think the unicode-segmentation library should be taken into account for this.
https://gitlab.redox-os.org/redox-os/termion/-/issues/171
CI failed at building with stable toolchain
2019-07-27T05:24:22Z
akitsu-sanae
CI failed at building with stable toolchain
In some merge requests, CI failed with
```
$ cargo +stable build --verbose
error: toolchain 'stable-x86_64-unknown-linux-gnu' is not installed
```
I think that some CI config mistakes cause this.
CI failed at:
* https://gitlab.redox-os...
In some merge requests, CI failed with
```
$ cargo +stable build --verbose
error: toolchain 'stable-x86_64-unknown-linux-gnu' is not installed
```
I think that some CI config mistakes cause this.
CI failed at:
* https://gitlab.redox-os.org/redox-os/termion/merge_requests/164
* https://gitlab.redox-os.org/redox-os/termion/merge_requests/165
* current master
https://gitlab.redox-os.org/redox-os/termion/-/issues/170
Ctrl+shift+Char sends the same event as Ctrl+Char
2019-06-26T09:43:12Z
msirringhaus
Ctrl+shift+Char sends the same event as Ctrl+Char
`Ctrl+Shift+a` currently sends `Key::Ctrl('a')`
It would be really good, if it would send an upper case char if Shift is pressed as well
`Ctrl+Shift+a => Key::Ctrl('A')`
The interface is already prepared for that, as `Key::Ctrl(char)`...
`Ctrl+Shift+a` currently sends `Key::Ctrl('a')`
It would be really good, if it would send an upper case char if Shift is pressed as well
`Ctrl+Shift+a => Key::Ctrl('A')`
The interface is already prepared for that, as `Key::Ctrl(char)` could send both.
Same for Alt.
https://gitlab.redox-os.org/redox-os/termion/-/issues/168
[question] async_stdin and keys()
2020-09-02T18:20:34Z
doums
[question] async_stdin and keys()
Hi,
I noted that while being in `async_stdin` "mod" the `keys()` method does not return proper events. For example if I use the code below, `Left` key is not recognized. If I use `let mut it = stdin.keys()` instead of `termion::async_st...
Hi,
I noted that while being in `async_stdin` "mod" the `keys()` method does not return proper events. For example if I use the code below, `Left` key is not recognized. If I use `let mut it = stdin.keys()` instead of `termion::async_stdin()` this works well. Can someone explain me why ?
```
use std::io;
use std::io::{stdin, stdout, Read, Write};
use termion;
use termion::event::Key;
use termion::input::TermRead;
use termion::raw::IntoRawMode;
fn main() -> Result<(), io::Error> {
let mut stdout = io::stdout().into_raw_mode()?;
let mut stdin = termion::async_stdin();
// let mut stdin = io::stdin();
let mut it = stdin.keys();
loop {
let b = it.next();
if let Some(event) = b {
match event? {
Key::Left => println!("LEFT"),
Key::Char('q') => break,
_ => {}
}
}
stdout.flush()?;
}
Ok(())
}
```
https://gitlab.redox-os.org/redox-os/termion/-/issues/167
Build fails on Windows
2020-11-22T08:09:35Z
Sebastian Thiel
Build fails on Windows
This is a cross-post from the respective issue in [`disk usage analyzer`](https://github.com/Byron/dua-cli/issues/2), and happens `stable-x86_64-pc-windows-msvc` - `rustc 1.35.0 (3c235d560 2019-05-20)`.
*I thought Termion was working on...
This is a cross-post from the respective issue in [`disk usage analyzer`](https://github.com/Byron/dua-cli/issues/2), and happens `stable-x86_64-pc-windows-msvc` - `rustc 1.35.0 (3c235d560 2019-05-20)`.
*I thought Termion was working on windows by now*, and am surprised it fails due to module errors. Maybe these are unrelated?
Thanks for your advice
<details>
```
error[E0433]: failed to resolve: maybe a missing `extern crate sys;`?
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\lib.rs:24:9
|
24 | pub use sys::size::terminal_size;
| ^^^ maybe a missing `extern crate sys;`?
error[E0433]: failed to resolve: maybe a missing `extern crate sys;`?
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\lib.rs:25:9
|
25 | pub use sys::tty::{is_tty, get_tty};
| ^^^ maybe a missing `extern crate sys;`?
error[E0433]: failed to resolve: maybe a missing `extern crate sys;`?
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\async.rs:5:5
|
5 | use sys::tty::get_tty;
| ^^^ maybe a missing `extern crate sys;`?
error[E0433]: failed to resolve: maybe a missing `extern crate sys;`?
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:29:5
|
29 | use sys::attr::{get_terminal_attr, raw_terminal_attr, set_terminal_attr};
| ^^^ maybe a missing `extern crate sys;`?
error[E0432]: unresolved import `sys`
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:28:5
|
28 | use sys::Termios;
| ^^^ maybe a missing `extern crate sys;`?
error[E0425]: cannot find function `get_tty` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\async.rs:14:36
|
14 | thread::spawn(move || for i in get_tty().unwrap().bytes() {
| ^^^^^^^ not found in this scope
error[E0425]: cannot find function `get_tty` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\async.rs:43:36
|
43 | thread::spawn(move || for i in get_tty().unwrap().bytes() {
| ^^^^^^^ not found in this scope
error[E0425]: cannot find function `set_terminal_attr` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:45:9
|
45 | set_terminal_attr(&self.prev_ios).unwrap();
| ^^^^^^^^^^^^^^^^^ not found in this scope
error[E0425]: cannot find function `get_terminal_attr` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:90:23
|
90 | let mut ios = get_terminal_attr()?;
| ^^^^^^^^^^^^^^^^^ not found in this scope
error[E0425]: cannot find function `raw_terminal_attr` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:93:9
|
93 | raw_terminal_attr(&mut ios);
| ^^^^^^^^^^^^^^^^^ not found in this scope
error[E0425]: cannot find function `set_terminal_attr` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:95:9
|
95 | set_terminal_attr(&ios)?;
| ^^^^^^^^^^^^^^^^^ not found in this scope
error[E0425]: cannot find function `set_terminal_attr` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:106:9
|
106 | set_terminal_attr(&self.prev_ios)?;
| ^^^^^^^^^^^^^^^^^ not found in this scope
error[E0425]: cannot find function `get_terminal_attr` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:111:23
|
111 | let mut ios = get_terminal_attr()?;
| ^^^^^^^^^^^^^^^^^ not found in this scope
error[E0425]: cannot find function `raw_terminal_attr` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:112:9
|
112 | raw_terminal_attr(&mut ios);
| ^^^^^^^^^^^^^^^^^ not found in this scope
error[E0425]: cannot find function `set_terminal_attr` in this scope
--> C:\Users\Roy\.cargo\registry\src\github.com-1ecc6299db9ec823\termion-1.5.2\src\raw.rs:113:9
|
113 | set_terminal_attr(&ios)?;
| ^^^^^^^^^^^^^^^^^ not found in this scope
error: aborting due to 15 previous errors
Some errors occurred: E0425, E0432, E0433.
For more information about an error, try `rustc --explain E0425`.
error: Could not compile `termion`.
warning: build failed, waiting for other jobs to finish...
```
https://gitlab.redox-os.org/redox-os/termion/-/issues/166
Implement a way to parse color strings
2019-09-21T00:22:23Z
Ophir LOJKINE
Implement a way to parse color strings
Currently, all colors are individual structs. There is no easy way to create a color from a string.
Some projects use [lengthy macros](https://github.com/Canop/broot/blob/8258d419780c08b23cd2bdcc24ff6fbbcb83273b/src/skin_conf.rs#L32-L85)...
Currently, all colors are individual structs. There is no easy way to create a color from a string.
Some projects use [lengthy macros](https://github.com/Canop/broot/blob/8258d419780c08b23cd2bdcc24ff6fbbcb83273b/src/skin_conf.rs#L32-L85) to achieve that.
It would be really useful if there were a way to parse a color from a string.
https://gitlab.redox-os.org/redox-os/termion/-/issues/165
Running "cargo test" messes with line breaks in my terminal
2019-02-13T21:05:49Z
Valentin Lorentz
Running "cargo test" messes with line breaks in my terminal
Hi,
Sorry for the title, but I don't know how to put it. Often, "cargo test" makes line breaks behave as if a carriage return is missing; both while cargo is running and after.
Here is a screenshot:
![screenshot](/uploads/81531c32df95...
Hi,
Sorry for the title, but I don't know how to put it. Often, "cargo test" makes line breaks behave as if a carriage return is missing; both while cargo is running and after.
Here is a screenshot:
![screenshot](/uploads/81531c32df953fdef8c0cc062f3d8ae6/Capture_d_écran_2019-02-13_21-59-32.png)
I'm using gnome-terminal with zsh/oh-my-zsh.
https://gitlab.redox-os.org/redox-os/termion/-/issues/164
Panic on busy mouse events
2019-01-28T23:07:21Z
Robert Cutajar
Panic on busy mouse events
Problem: With the `MouseTerminal` in lxterminal, press mouse and drag the pointer outside of the terminal window and fiddle with it a lot => panic:
```
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/opt...
Problem: With the `MouseTerminal` in lxterminal, press mouse and drag the pointer outside of the terminal window and fiddle with it a lot => panic:
```
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:345:21
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:511
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:426
6: rust_begin_unwind
at libstd/panicking.rs:337
7: core::panicking::panic_fmt
at libcore/panicking.rs:92
8: core::panicking::panic
at libcore/panicking.rs:53
9: <core::option::Option<T>>::unwrap
at /checkout/src/libcore/macros.rs:20
10: termion::event::parse_csi::{{closure}}
at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/termion-1.5.1/src/event.rs:161
11: termion::event::parse_csi
at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/termion-1.5.1/src/event.rs:166
12: termion::event::parse_event
at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/termion-1.5.1/src/event.rs:118
13: termion::input::parse_event
at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/termion-1.5.1/src/input.rs:99
14: <termion::input::EventsAndRaw<R> as core::iter::iterator::Iterator>::next
at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/termion-1.5.1/src/input.rs:77
15: <termion::input::Events<R> as core::iter::iterator::Iterator>::next
at ~/.cargo/registry/src/github.com-1ecc6299db9ec823/termion-1.5.1/src/input.rs:38
16: two::ui::grinui::GrinUI::process
at src/ui/grinui.rs:59
17: two::ui::grinui::GrinUI::react_once
at src/ui/grinui.rs:54
18: two::ui::grin::Grin::wait
at src/ui/grin.rs:63
19: two::main::{{closure}}
at src/main.rs:23
20: <core::result::Result<T, E>>::and_then
at /checkout/src/libcore/result.rs:621
21: two::main
at src/main.rs:22
22: std::rt::lang_start::{{closure}}
at /checkout/src/libstd/rt.rs:74
23: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
24: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:105
25: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392
at libstd/rt.rs:58
26: std::rt::lang_start
at /checkout/src/libstd/rt.rs:74
27: main
28: __libc_start_main
29: _start
```
https://gitlab.redox-os.org/redox-os/termion/-/issues/163
get terminal size with alternate file descriptor (e.g. stderr)
2020-06-08T21:03:56Z
xPMo
get terminal size with alternate file descriptor (e.g. stderr)
**Motivation:** I discovered this project via the lovely terminal application [broot](https://github.com/Canop/broot). One of the biggest problems I have is difficulty capturing the selection like fzf allows: `selection="$(fzf)"`. Instea...
**Motivation:** I discovered this project via the lovely terminal application [broot](https://github.com/Canop/broot). One of the biggest problems I have is difficulty capturing the selection like fzf allows: `selection="$(fzf)"`. Instead, the broot dev recommends [this ugly workaround](https://github.com/Canop/broot#use-broot-for-navigation). I forked broot to use stderr everywhere, and everything works just as before. However, when I try to capture selection, it panics on `get_terminal_size` since stdout is no longer a terminal.
**Proposed solution:** Since #89 is already proposing an API change on get_terminal_size, I think instead we should leave `get_terminal_size` alone, and add a new fn like `get_filedesc_size` with both this and #89's changes. This would then only be a minor version bump in semver.
https://gitlab.redox-os.org/redox-os/termion/-/issues/162
[question] quote/ecape user input
2018-12-26T01:50:29Z
Tim Glabisch
[question] quote/ecape user input
this is more a question, not an issue.
i played with the ion shell and liner. i've the problem that the suggestion is broken, when i print the suggestion of "/".
i guess the problem is that the content of the suggestion is not escaped/q...
this is more a question, not an issue.
i played with the ion shell and liner. i've the problem that the suggestion is broken, when i print the suggestion of "/".
i guess the problem is that the content of the suggestion is not escaped/quoted. in my case "\r" in a filename destroys the formatting of the suggestion. liner has todo's releated to this problem: https://gitlab.redox-os.org/redox-os/liner/blob/master/src/editor.rs#L378
i am wondering if termion provides any kind of high lvel solution for this?
is this on the roadmap or out of scope of termion?
https://gitlab.redox-os.org/redox-os/termion/-/issues/160
unable to use full Rgb colors when terminal has a color scheme
2018-12-02T13:02:52Z
Nathaniel McIntosh
unable to use full Rgb colors when terminal has a color scheme
As described in the title, when using a terminal color scheme. I'm unable to use custom colors. I'm using pywal in this instance if that helps. Is there a way to bypass this? Thanks.
As described in the title, when using a terminal color scheme. I'm unable to use custom colors. I'm using pywal in this instance if that helps. Is there a way to bypass this? Thanks.
https://gitlab.redox-os.org/redox-os/termion/-/issues/158
Dropping of AlternateScreen does not flush stdout
2019-01-02T06:22:11Z
Magnus Bergmark
Dropping of AlternateScreen does not flush stdout
When dropping alternate screen `stdout` is not flushed, leading to messages on `stderr` disappearing, or other processes using the same `stdout` not having any output visible.
See https://gitlab.redox-os.org/redox-os/termion/blob/d2945c...
When dropping alternate screen `stdout` is not flushed, leading to messages on `stderr` disappearing, or other processes using the same `stdout` not having any output visible.
See https://gitlab.redox-os.org/redox-os/termion/blob/d2945cd36c452824aeabd5d7c13980d9567eb8a2/src/screen.rs#L63-67
Here is a sample bin showing the issue:
```rust
extern crate termion;
use std::io;
use std::io::Write;
use termion::raw::IntoRawMode;
fn main() {
let raw = io::stdout().into_raw_mode().unwrap();
let screen = termion::screen::AlternateScreen::from(raw);
println!("This is stdout in alt screen.\r");
eprintln!("This is stderr in alt screen.\r");
::std::thread::sleep(::std::time::Duration::from_secs(1));
drop(screen);
// Comment this out to get both messages displayed:
// io::stdout().flush().ok();
eprintln!("This is stderr outside alt screen.\r");
println!("This is stdout outside alt screen.\r");
}
```
First two messages are shown for a second, then only the message on stdout is displayed after the screen is restored. If stdout is flushed before, then the alternate screen is really stopped before anything is written to stderr. As it is now, the two buffers are flushed independently.
This also causes problems with things like this pseudo code:
```rust
fn main() {
let command = select_command_in_alternate_screen()?;
fork_exec_wait(command);
println!("Done");
}
fn select_command_in_alternate_screen() -> Result<String, ()> {
let mut terminal = setup_alternate_screen();
// …
return Ok(command);
// implied drop(terminal) at the end of the function
}
```
The forked process (created using `std::process::Command`, for example) inherits the same stdout and stderr FDs and starts writing to them before this process has flushed its buffers, so output on both stdout and stderr is lost as soon as the `"Done"` message is finally flushed.
I think manually flushing at the `drop` means that it would be a lot easier to use alternate screens in RAII-patterns that Rust is so good at. Right now I manually need to place `flush` calls at each call site after a function using an alternate screen to be sure no message after it is lost.
https://gitlab.redox-os.org/redox-os/termion/-/issues/157
Raw mode is still line buffered.
2019-02-04T07:19:09Z
Tom Dagenais
Raw mode is still line buffered.
Since `io::std::Stdout` is line-buffered with `LineWriter` see here: https://github.com/rust-lang/rust/blob/master/src/libstd/io/stdio.rs#L342-L347 . Writing through a `RawTerminal` which wraps stdout, as shown in the documentation, stil...
Since `io::std::Stdout` is line-buffered with `LineWriter` see here: https://github.com/rust-lang/rust/blob/master/src/libstd/io/stdio.rs#L342-L347 . Writing through a `RawTerminal` which wraps stdout, as shown in the documentation, still results in line buffering.
```rust
use termion::raw::IntoRawMode;
use std::io::{Write, stdout};
fn main() {
let mut stdout = stdout().into_raw_mode().unwrap();
for _ in 0..1000 {
write!(stdout, "text\n").unwrap();
}
}
```
`strace -c` will show 1000 write calls as the stream is still line-buffered which contradicts the documentation of `RawTerminal`.
https://gitlab.redox-os.org/redox-os/termion/-/issues/156
Kinda working Windows shim
2018-12-17T17:52:19Z
John Doneth
Kinda working Windows shim
If it's of any interest I have managed to get Termion kinda working on Windows by using another library called [termiWin](https://github.com/ChristianVisintin/termiWin). By compiling and linking it with the `cc-rs` crate at build time an...
If it's of any interest I have managed to get Termion kinda working on Windows by using another library called [termiWin](https://github.com/ChristianVisintin/termiWin). By compiling and linking it with the `cc-rs` crate at build time and using it as a shim to process and translate `tcsetattr`, `tcgetattr` and `cfmakeraw` calls I can get some of the examples to function.
Most of the examples don't seem to function as they should, and I can't test to make sure because I don't currently have access to a Linux device, but most notably the commie seems to run fine.
Link:
[https://github.com/JohnDoneth/termion](https://github.com/JohnDoneth/termion)
https://gitlab.redox-os.org/redox-os/termion/-/issues/154
Raw Terminal mode, calling cursor_pos() causes first character to be ignored.
2019-03-14T19:42:25Z
Omar (gatoWololo)
Raw Terminal mode, calling cursor_pos() causes first character to be ignored.
Two simple lines:
```rust
let mut stdout : RawTerminal<Stdout> = stdout().into_raw_mode().unwrap();
let (x, y) = stdout.cursor_pos().unwrap();
```
Now, if I try to read per byte input with:
```rust
for c in stdin.keys() {
...
}
```
T...
Two simple lines:
```rust
let mut stdout : RawTerminal<Stdout> = stdout().into_raw_mode().unwrap();
let (x, y) = stdout.cursor_pos().unwrap();
```
Now, if I try to read per byte input with:
```rust
for c in stdin.keys() {
...
}
```
The very first key will be ignored always. This is true anytime after calling cursor_pos().
https://gitlab.redox-os.org/redox-os/termion/-/issues/153
Usefulness of AsyncReader
2018-08-26T13:59:57Z
Michael Noronha
Usefulness of AsyncReader
I'm somewhat confused about the existence of `async_stdin`, given we can't poll from it. I understand that there isn't a very straightforward way to poll non-blocking from `stdin` that is also cross-platform, but is `async_stdin` differe...
I'm somewhat confused about the existence of `async_stdin`, given we can't poll from it. I understand that there isn't a very straightforward way to poll non-blocking from `stdin` that is also cross-platform, but is `async_stdin` different from me just manually calling `.next()` in a loop?
https://gitlab.redox-os.org/redox-os/termion/-/issues/151
Resize notification
2019-01-16T07:07:47Z
Tim
Resize notification
Is there a way to be notified somehow when the terminal is resized, so I can redraw things correctly? Various programs seem capable of this but I can't see a way to do it with termion.
Is there a way to be notified somehow when the terminal is resized, so I can redraw things correctly? Various programs seem capable of this but I can't see a way to do it with termion.
https://gitlab.redox-os.org/redox-os/termion/-/issues/149
TermRead read_line() conflicts with BufRead read_line()
2018-06-16T04:18:39Z
Michael Aaron Murphy
mmstick@pm.me
TermRead read_line() conflicts with BufRead read_line()
*Created by: zedzorander*
This might be a compiler issue but... I am working on a network card game where I need to use a key event and a BufReader. I get an error message when I call the read_line() function on the BufReader. The compi...
*Created by: zedzorander*
This might be a compiler issue but... I am working on a network card game where I need to use a key event and a BufReader. I get an error message when I call the read_line() function on the BufReader. The compiler can't determine which read_line() function to call. Here's an example:
extern crate termion;
use termion::event::Key;
use termion::input::TermRead;
use termion::raw::IntoRawMode;
use std::io::{Write, stdout, stdin, BufRead, BufReader};
use std::fs::File;
fn main() {
let file = File::open("/etc/passwd").unwrap();
let reader = BufReader::new(&file);
let mut line = String::new();
reader.read_line(&line).unwrap();
let stdin = stdin();
let mut stdout = stdout().into_raw_mode().unwrap();
for c in stdin.keys() {
match c.unwrap() {
Key::Char('q') => break,
Key::Char('x') => {
write!(stdout, "Key x\r\n").unwrap();
stdout.flush().unwrap();
},
_ => {}
}
stdout.flush().unwrap();
}
}
Here is the error message:
error[E0034]: multiple applicable items in scope
--> src/main.rs:14:12
|
14 | reader.read_line(&line).unwrap();
| ^^^^^^^^^ multiple `read_line` found
|
= note: candidate #1 is defined in an impl of the trait `std::io::BufRead` for the type `std::io::BufReader<_>`
= note: candidate #2 is defined in an impl of the trait `termion::input::TermRead` for the type `_`
The problem currently can be resolved by declaring reader this way:
let reader: &BufRead = &BufReader::new(&file);
let mut line = String::new();
reader.read_line(&line).unwrap();
But that's pretty ugly and was a bit of a pain to figure out.