Re: [dev] [sandy] [PATCH] VIM key bindings.

From: Raphaël Proust <>
Date: Thu, 10 Jul 2014 13:41:14 +0100

On Thu, Jul 10, 2014 at 1:12 PM, Silvan Jegen <> wrote:
> On Thu, Jul 10, 2014 at 11:52 AM, Raphaël Proust <> wrote:
>> On Thu, Jul 10, 2014 at 1:56 AM, Dimitris Zervas <> wrote:
>> The trick that Yi uses is quite clever and not very complicated:
>> keyboard input is passed to a lexer/parser which can be rewritten to
>> provide alternative bindings. Treating keyboard events like that
>> actually makes a lot of sense. It is not very specific to any
>> programming paradigm and could be implemented in C (with a recursive
>> descent parser if yacc is deemed to suck to much).
> Actually, I do not think you will need a "real" recursive parser. It
> should be enough to use a finite state machine since you won't have
> any recursively nested key bindings.

Yes, a state machine should be enough…

> I am not completely sure how to implement this but it sounds like a
> very interesting problem. The states transition should probably look
> something like this
> (count)? -> (operation)->(object)

Operation is also optional and defaults to move (i.e., "5w" moves five
words forward while "5dw" deletes five words forwards). And in vi[m]
objects can have a count too. (e.g., "5dw" deletes one word five
times, "d5w" deletes 5 words). And the object depends on the
operation. And operation when repeated applies to the whole line
(e.g., "dd", "yy"). Some operations also have optional qualifiers
(e.g., yank/delete can take register).

So the transition is a bit complicated. Well the vim one is, we can
have something slightly saner.

Also, mode changes can be integrated into this model. The keypress `v`
gets into a different part of the state machine, &c.

Raphaël Proust
Received on Thu Jul 10 2014 - 14:41:14 CEST

This archive was generated by hypermail 2.3.0 : Thu Jul 10 2014 - 14:48:11 CEST