Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make more use of Read and Write #108

Open
felipesere opened this issue Dec 22, 2021 · 5 comments
Open

Make more use of Read and Write #108

felipesere opened this issue Dec 22, 2021 · 5 comments

Comments

@felipesere
Copy link

Creating a Term from Read and Write was added in #34 (merged #93 ) which is pretty cool 馃帀
I am using that mechanism to write a TestTerminal that buffers calls to Write internally and has prepared content for Read.

My code uses term.read_line() though, which to my surprise uses stdin() directly.
I was expecting that to go through Read.

Is that something that could be adjusted? I can probably try and submit a PR?

@grunweg
Copy link
Contributor

grunweg commented Jan 20, 2022

@felipesere I just noticed that the read field of a ReadWrite pair is currently not used at all. To me (just an outsider, not a maintainer), that feels like an oversight and your patch seems like a natural completion of the work in #93.

dtolnay pushed a commit to dtolnay-contrib/console that referenced this issue Feb 4, 2022
This PR adds a `retain-for` duration argument to the console. Additionally, 
I have modified the proto to not include the total_time for tasks,resources and
async ops and instead contain `created_at` and `dropped_at` fields. A separate 
`console-util` crate has been added that contains the logic for parsing a duration
string. 

Close console-rs#108

Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
@pksunkara
Copy link
Collaborator

Sorry for the late reply but I would welcome a PR.

@grunweg
Copy link
Contributor

grunweg commented May 6, 2022

Attempted fix at #123. I couldn't test that easily. @felipesere If you get the chance to do so, your feedback would be very welcome.

(Besides, I would be interested in your setup for the TestTerminal crate: I'm interested in testing some changes to the dialoguer crate; sounds like your setup fits my use case. Any chance you can share something about this?)

@FelixSelter
Copy link

FelixSelter commented May 26, 2023

@pksunkara Any news on this? This an essential feature in my application. I could continue working on this if you comment on the pr?

As far as I can tell these are the lines using stdin:

These ones seems problematic as well:

I would check if we have a ReadWritePair and use the reader. Otherwise the functions above. Does that sound right?

What about implementing these four functions for the TermTarget Enum:

impl TermTarget {
    fn read(&self, buf: &mut [u8]) -> io::Result<usize> {
        if let TermTarget::ReadWritePair(pair) = self {
            todo!()
        } else {
            io::stdin().read(buf)
        }
    }
    fn read_line(&self, buf: &mut String) -> io::Result<usize> {
        if let TermTarget::ReadWritePair(pair) = self {
            todo!()
        } else {
            io::stdin().read_line(buf)
        }
    }
    fn read_secure(&self, buf: &mut &[u8]) -> io::Result<String> {
        if let TermTarget::ReadWritePair(pair) = self {
            todo!()
        } else {
            read_secure()
        }
    }
    fn read_single_key(&self, buf: &mut &[u8]) -> io::Result<Key> {
        if let TermTarget::ReadWritePair(pair) = self {
            todo!()
        } else {
            read_single_key()
        }
    }
}

Then we do not need to worry about any checking in the Term struct

@pksunkara
Copy link
Collaborator

pksunkara commented May 27, 2023

I would welcome a PR here. But, I haven't been focusing on maintaining console anymore. So, you will have to wait for mitsuhiko to review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants