vi-style keybinding mode?

[bsidhom]

Adding more general readline-style support could make it much easier to edit/reuse long inputs, especially given that there's no mouse support. I assume that there's some baked-in Emacs-style bindings at the moment, but my fingers aren't familiar with that. 🙂

It may be possible to get this support for free (e.g., using configuration via .inputrc) with a readline-like crate, assuming such a thing exists.

[sharkdp]

We currently use rustyline as a library. It does not seem to support this feature, unfortunately (fellow vim user here):

• vi modal indicator kkawakam/rustyline#208
• Add support for inputrc configuration kkawakam/rustyline#303

[sharkdp]

Might be worth looking into https://github.com/nushell/reedline

[bsidhom]

Those bugs seem to relate to a ~/.inputrc-like config. The existence of InputMode and the vi mode section on crates.io suggest that this can be enabled somehow in rustyline. (I haven't looked into this yet.)

On the other hand, reedline does look pretty slick. Setting up vi-mode is as simple as changing the import line and editor instantiation in the example:

use reedline::{DefaultPrompt, Reedline, Signal, Vi};
let mut line_editor = Reedline::create().with_edit_mode(Box::new(Vi::default()));

I wonder if either supports a WASM target, which may allow us to get rid of the JS terminal emulator in "desktop" mode on the web.

[sharkdp]

which may allow us to get rid of the JS terminal emulator in "desktop" mode on the web.

I don't see how? We would not need a terminal emulator + readline interface (which is what jquery.terminal provides for us). But we would still need a terminal emulator for the browser. Something like https://xtermjs.org/ (which is extremely low-level).

[bsidhom]

You’re right. I wanted to say “pseudo terminal emulator” to describe that but I didn’t mean ptty. A true terminal emulator would give better fidelity and parity with the cli app. Anyway, it could let us drop the…terminal emulator emulator? I assume xtermjs is pretty heavy, so it might make sense to fork the web app or conditionally load resources in that case based on the device type (assuming mobile UI comes to fruition).