External printer sometimes omits messages until more input is given #629
Comments
|
Sorry but I cannot reproduce on linux/macosx: $ uname -a
Linux archlinux 5.17.5-arch1-1 #1 SMP PREEMPT Wed, 27 Apr 2022 20:56:11 +0000 x86_64 GNU/Linux% uname -a
Darwin Gwenaels-MacBook-Air.local 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41 PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
% echo $TERM
xterm-256colorI will try to investigate on a FreeBSD VM... fn main() -> Result<()> {
+ env_logger::init();
let mut rl = Editor::<()>::new();
let mut printer = rl.create_external_printer()?;$ RUST_LOG=rustyline=debug cargo run --example external_print 2> debug.logThanks. |
|
I'm happy to help. I'm not much familiar with C++, so I didn't get the example compiled yet. But I found out something already: I cannot reproduce it if I run the example from the This is how my [package]
name = "readnwrite"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
rustyline = { git = "https://github.com/kkawakam/rustyline/", rev="280e71191fef234c698fe1d94dedc270a6f37c33" }
#rustyline = "9.1.2"
rand = "0.8.5"
env_logger = "0.9.0"Can you reproduce the behavior with a separate crate that uses these dependencies? This is the debug output using And text output was as follows: |
When I compile it with Note that when I run the example from |
|
Thanks for your investigations. |
|
My deepest apologies! I wrongly used the latest commit of the example file ( With the current version in |
|
No worry. |
|
Should I close this issue then? (Or you can do it too.) |
|
Please, do. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using FreeBSD and xterm and tried the new external printer feature.
When I type in text, the program and/or terminal sometimes gets into a state where no more messages are being emitted. I used this example code, with slightly adjusted timings:
This is how my terminal looks like after I type in some text when I'm unlucky:
At this point, no more output will be created, even if I wait for a long time. I then typed a few
xcharacters, and this happened:Note that also an
fappeared afterghdflghdfjkhdand before thexxxxxx. Thatfmust have been stuck somewhere because I didn't enter it after the state appeared to be blocked.Messages #4 through #31 got lost in this example.
My setup:
The text was updated successfully, but these errors were encountered: