Interactive REPL Interface

[nixpulvis]

In addition to the basic support for reading programs from a non-interactive input, we need to have the ability to run in interactive mode, with prompts, and the full suite of features.

• [x] Prompt
• [x] Cursor movement
  • [ ] Multi-line programs (\ line continuations, and incomplete syntax)
  • [ ] #30 More cursor movements
• [x] History
• [ ] #29 sh-like completions
• [ ] #23 Signals

Modern

• [ ] #48 Modern completion framework
• [ ] Syntax highlighting

Open Questions

• [ ] Mouse?

[nixpulvis]

I want to move all stream processing out of main.rs and into the fancy new repl module. I believe BufReadDecoder will be needed.

[nixpulvis]

So here's an idea (does lalrpop support it?), we return a parse error on incomplete syntax, and that's the input to the function that drives highlighting, completion, history selection, etc.

As such it'll need to be an AST of the syntax so far, and some expected set. The parser must be somewhat performant to do this on each action in raw mode, we may need to buffer by token or some larger piece of grammar. This should be easy-ish by using one of the composite grammars from the LALRPOP generated parsers.

[nixpulvis]

The initial sh style completion feature will be simple and fast enough to run inline, but after that point a more robust asynchronous implementation is needed.

[do-you-dare]

What would the mouse features be? Asking just out of curiosity :p By the way, nice project!

[nixpulvis]

@dread-uo I've been so busy writing all this POSIX stuff I haven't thought much about it. I spent a good part of tonight working on making the raw terminal mode a cargo feature... mouse actions could go on top of that.

Looking at MouseEvent looks like we get everything we'd need. Terminals are netoriously known for not being heavy on mouse interactions, but I think there are a few nice things we could try. As a general rule of thumb, mouse actions should be things you are doing not as part of a normal text REPL workflow. For example a mouse button to close a search mode would make me cry.

1. I already have dreams of a mode that operates like a shared tmux session, perhaps the mouse could show up as a colored cursor on the other persons terminal window.
2. While many terminal emulators support clicking links and things like that, we could have our own logic, and include more kinds of links.
3. There's something really interesting about having shell ASTs and the ability to click the syntax, maybe something like https://explainshell.com/ could be made to work well.

Basically who knows at this point. Thanks for the question. Let me know if you end up using the shell at all, or want to help :wink:

[nixpulvis]

In order to support current and future needs for completion, here is a more complete design.

• complete (combine the below functions)
• complete_command
  • complete_builtin
  • complete_function
  • complete_executable
• complete_path (includes ~, and globs)
• complete_variable
• complete_job
• complete_syntax

enum Completion {
    None,
    Partial(String, HashSet<String>),
    Complete(String),
}

Still need to figure out the best place to put the completion for the fish style last history completion.

[nixpulvis]

A good list of features to support to be inline with sh can be found here under the section "Command Line Editing".