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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rustyline in the web #377

Open
segeljakt opened this issue May 5, 2020 · 9 comments
Open

Rustyline in the web #377

segeljakt opened this issue May 5, 2020 · 9 comments
Labels

Comments

@segeljakt
Copy link
Contributor

This is probably a long shot, but have you considered integrating rustyline with web-based terminals? For example, https://github.com/xtermjs/xterm.js/.

@gwenn gwenn added the question label May 5, 2020
@segeljakt
Copy link
Contributor Author

segeljakt commented May 10, 2020

I have created these bindings for xterm-js:

@jmmv
Copy link

jmmv commented May 15, 2020

I think more than coupling rustyline to any web-specific interface... it'd be better if rustyline could be configured to read from and write to arbitrary streams, instead of hardcoding the use of stdin and stdout (which don't seem to be available in the WASM target). That way, xterm-js-rs could provide small wrappers to extract characters from the web interface and feed them into rustyline, and then take rustyline's output and feed it back into the web.

(Actually came to this bug tracker today to file this specific feature request and found this existing bug, so thought I'd comment.)

@segeljakt
Copy link
Contributor Author

segeljakt commented May 15, 2020

@jmmv sounds excellent to me 👍 I can fix it on my end if Rustyline intends to use it

@jmmv
Copy link

jmmv commented May 15, 2020

That's just a drive-by comment though ;) I'm not involved with this project. But I was considering giving a try to what I proposed because... well, I need it for a project I'm working on, and your xterm-js-rs crate appeared just in time for my needs!

@segeljakt
Copy link
Contributor Author

Alright, I created the bindings for the purpose of a programming language I have been working on https://github.com/segeljakt/arc-script
I've been hoping it could be integrated into one or more of the REPLs in Rust's ecosystem

@dlight
Copy link

dlight commented Oct 20, 2020

I'm also interested! @segeljakt did you eventually fork rustyline or went with another solution?

@segeljakt
Copy link
Contributor Author

@dlight I did not have time to work on it but it would be really cool to see it running. Eventually I will get to it. Otherwise, if someone wants to give it a shot I could help out on the side.

@jmmv
Copy link

jmmv commented Oct 21, 2020

I have a project (https://github.com/jmmv/endbasic/) where I used rustyline for the command line interface. In porting this to the web, I had to scrape the rustyline dependency because it wouldn't work with it.

Last week, I spent some time trying to unify the CLI (still using rustyline) and the web UI, and the way I had to go about it was to create an abstraction layer to read keys from a console. The key part is making such interface async, which for rustyline would mean making everything async too. See endbasic/endbasic@5b20489 for how I did this (which also meant removing the use of rustyline, but I'd love to put it back), but note that this commit is still unmerged and it might vanish.

@dlight
Copy link

dlight commented Oct 21, 2020

There are ways to shim stdout for the web, like wasm-glue and this nightly-only feature. I'm not finding how to shim stdin right now, at least not for wasm32-unknown-unknown, but it should be possible - after all, many C programs with stdin were ported to the web, and whatever works for C should work for Rust with a little unsafe. If done right, Rustyline and other programs would work unmodified.

Perhaps a workaround is to use the wasm32-unknown-emscripten backend and use usual the emscripten ways to configure stdin.

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

No branches or pull requests

4 participants