Support vi mode

[XVilka]

Like in readline

[dbuenzli]

Please be more specific in your requests. What does it entails ? How does that overlap with #12 ?

[XVilka]

well, not sure what can be more specific, see the help of readline:

8.5 Readline vi Mode

While the Readline library does not have a full set of vi editing functions, it does contain enough to allow simple editing of the line. The Readline vi mode behaves as specified in the POSIX standard.

In order to switch interactively between emacs and vi editing modes, use the ‘set -o emacs’ and ‘set -o vi’ commands (see The Set Builtin). The Readline default is emacs mode.

When you enter a line in vi mode, you are already placed in ‘insertion’ mode, as if you had typed an ‘i’. Pressing ESC switches you into ‘command’ mode, where you can edit the text of the line with the standard vi movement keys, move to previous history lines with ‘k’ and subsequent lines with ‘j’, and so forth.

See also the cheatsheet https://catonmat.net/ftp/bash-vi-editing-mode-cheat-sheet.pdf

[dbuenzli]

well, not sure what can be more specific, see the help of readline:

Please understand that I'm not working for you in any sort of manner. What you get here is a courtesy.

If there is no support for what you want it's likely that either 1) I'm personally not interested in having it or 2) it's a topic I don't know about. As such, in order to maximize the chances that I consider your requests be precise in them, motivate them, propose designs, indicate what they entail for the project and how the problem could be approached.

Regarding this specific request I'm not planning in implementing this, but I'm not formally against it if someone comes up with a proper design proposal first, both at the API and implementation level.

Meanwhile, I'm closing this.

[nilsbecker]

For the record, I would also be interested in such a feature (which has been requested for utop for a long time).

I don't think I can propose a proper design. However, here some thoughts: In terms of API, I think there would be a minimal one. To install the vi mode, one could use a new toplevel directive, or if that's not possible, loading of a specific submodule. Then, the keyboard input would have to be processed by Down before handing it to the toplevel. Command mode would be invoked by ESC. in command mode the motion and editing commands above would be supported, and i would switch back to the usual insert mode.

I'm afraid I don't have sufficient understanding of how input processing works in Down to suggest an implementation. It seems that the motion commands https://github.com/dbuenzli/down/blob/21c5019293d9508f27816119668847ed1aad8f54/src/down.ml#L701-L752 have most of what's needed. So that list would need to be switchable in a state-dependent manner to use different shortcut keys when in command mode. In addition, some combined motion/editing key combinations (diw etc) would need to be combined from the basic building blocks there.

I would like to add that to me XVilka 's original request did not sound like asking for free labor -- I would see it as an opinion of what feature would make Down more useful, which may or may not be considered by anyone actually working on Down. XVilka then also supplied details of what the user interface would precisely look like.

[nilsbecker]

Another idea: could rlwrap ocaml work together with Down when rlwrap uses the vi mode of readline? I.e. could tab-completion still work, while the other shortcuts would not interfere? I just tried it out and it only worked half-way -- I could enter the command mode but after one motion command was then kicked back into insert mode.

[dbuenzli]

As I said I'm personally not interested in this feature so I'm not going to work on this in any manner -- unless someone wants to push cash on the table.

I don't think it's a huge amount of design work but it is it's not a trivial amount of it either and I neither have the time nor envy for it now or in the future.

Again if someone's willing to at least prototype something to clear the way a bit to see what it entails I will consider it --- it's not as if down.ml is an horribly long and/or convoluted piece of code, just print it and read it in your spare time.

I would like to add that to me XVilka 's original request did not sound like asking for free labor

I think I already explained the problem with XVilka's interaction. There's no need to comment this further.

[XVilka]

I never asked in free labor, sorry if it sounded like that! And the curse of knowledge was in place as well, using readline vi-mode daily, I forgot it is not widely known. My apologies.