fix(stdio): fix CJK input/deletion glitches by unifying prompt with rustyline

[Jiafei-Queen]

Problem

Currently, stdio.prompt (implemented via dialoguer) has issues handling CJK characters. When a user enters Chinese characters and tries to backspace, it causes byte-offset mismatches, leading to "ghost characters" or incorrect cursor positioning in the terminal.

Background

I noticed that Lune's REPL already uses rustyline for a superior interactive experience. However, the lune-std-stdio crate still relies on dialoguer for its Text prompt, creating a functional inconsistency between the REPL and script-driven prompts.

Proposed Change

I have implemented a local fix by swapping the PromptKind::Text branch in lune-std-stdio to use rustyline.

[Jiafei-Queen]

Btw, what's your take on adding a stdio.editor interface? I think exposing readLine and addHistory (backed by rustyline) would be a great addition to the standard library, as it allows for persistent history and more flexible terminal input than the current prompt API.

[CompeyDev]

FWIW, I think we should replace dialoguer entirely and have a very minimal, raw API for getting input (similar to stdio.readToEnd, but listen to typical characters like enter to stop reading rather than EOF). It could then be up to users for implementing more "prettier" interfaces from this API.

It feels a bit odd to represent a REPL interface for simple inputs, especially something like history backing. Those should be implemented as libraries insteead, IMO.

[Jiafei-Queen]

I think adding stdio.readLine (backed by rustyline) is a solid win—it fixes the CJK issues and, since it’s already in the binary, it’s basically a freebie. I’m fine with leaving the history backing part as a separate discussion for now.

The real catch here is that Luau is a sandbox. We can't just 'grab a library' like you do in Rust because we don’t have access to the raw TTY or OS calls. If the host (Lune) doesn't give us the tool, we're stuck.

Maybe in the future, we could look into adding FFI support (via libloading)? That way, the community could just load dynamic libraries and build our own ecosystems without needing to add everything to Lune's core. But for now, since we're trapped in the sandbox, we really need the host to provide a working line-editor.

[CompeyDev]

See #243, which has sort of been abandoned but does a solid 80% of the work for FFI. What I think we want to do is just read asynchronously from stdin using tokio IO, and hand that to a callback function or similar. I think that is the lowest common denominator which lets you do whatever you want with the raw input.

If you really do want a line editor like rustyline, we should consider a separate interface for it (like stdio.editor which you already recommended).