> The Readline API is much more extensive than that single function of course, and anyone using it can tweak all sorts of things about the library’s behavior. L

> The Readline API is much more extensive than that single function of course, and anyone using it can tweak all sorts of things about the library’s behavior. Library users can even add new functions that end users can configure via ~/.inputrc, meaning that Readline is very easy to extend. But, as far as I can tell, even Bash ultimately calls the simple readline() function to get input just as in the example above, though there is a lot of configuration beforehand. I feel that was designed backwards. Instead of having facilities so applications can extend readline by adding their own line editing functions specific to them, it should have facilities so users can add their own extensions and make them applicable to all applications that use readline. That would be cool. In particular, I would like to be able to extend it to add better multi-line editing support like what zsh's zle has. In zle, I can use `o` and `O` to create lines below or above the cursor, `j` and `k` to move to the next or previous line, `>>` to further indent the current line, etc. It's basically a mini-version of a vi buffer, right in the command line. In readline, you can insert a newline in the current prompt with Ctrl-V Ctrl-J, but to move between the lines, I have to move left or right beyond the beginning or end of the current line. Even worse, readline's history format doesn't support having a single entry for multi-line commands, like zsh does. :(