On Thu, Jul 10, 2014 at 1:12 PM, Silvan Jegen <s.jegen_AT_gmail.com> wrote:
> On Thu, Jul 10, 2014 at 11:52 AM, Raphaël Proust <raphlalou_AT_gmail.com> wrote:
>> On Thu, Jul 10, 2014 at 1:56 AM, Dimitris Zervas <dzervas_AT_dzervas.gr> 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.
Cheers,
--
______________
Raphaël Proust
Received on Thu Jul 10 2014 - 14:41:14 CEST