[implementations-list] On the software design of a vi/vim core

Mon Jun 29 12:59:59 CEST 2009

Marius,

Thanks for the nice comment. I do my keypress parsing in a specialized 
module that doesn't know anything about how commands actually work. It's 
a simple recursive descent parser, only unfolded to be called externally 
with each ProcessKey() event. The main parser state is whether commands 
are accepted, or only motions any more. At the beginning of a command, 
either will do, so for example all "g*" combinations are valid (gg, 
which is a motion, and gU, which is an operator). After an operator, 
only motions are allowed (dgg is valid, dgU doesn't make sense). Thus, I 
have the parser of g arguments split in two: ParseGArg() and 
ParseGArgOnlyMotions(). The trick is that ParseGArg() parses 
commands/operators, and then calls ParseGArgOnlyMotions() to check the rest!

Regards,

  -- Jon

Marius Andersen wrote:
> Jon,
>
> thanks for taking the time to share with us. Your scheme is very elegant; I particularly like how "motions" and "text objects" are seen as instances of a more general notion.
>
> I think the hardest part is keypress parsing. Simply binding keys like below won't do, as the second key binding will overwrite the first because it's more specific. That is, `daw' will work, but `dw' won't.
>
>     (global-set-key "d" 'delete)            ; reads motion
>     (global-set-key "da" 'delete-an-object) ; reads text object
>
> Of course, we can solve this particular problem by modifying `delete' -- "if the next character is `a', then call `delete-an-object'", or some such. But this is a tedious approach. What we really want is an easy way to express the fact that it's possible to type
>
>     d <motion>
>
> as well as
>
>     d a <text object>
>
> so that when our next bright idea suggests itself, we can merrily break all vi conventions by adding
>
>     d a æ <custom function>
>
> without having to rewrite `delete-an-object'.
>
> That is, we need some general representation (array, list) of what can follow what -- a "key grammar", if you will -- in place of the default approach of YAIE (Yet Another If Expression). (Viper has some scheme at its core, but it seems limited and the functions are littered with "special clauses" for things like macros etc. When I compare the comments with the actual code, I get the impression that Viper started off really beautiful and simple, but veered into complexity as the not-so-obvious complications of certain vi keys revealed themselves.)
>
> Any comments on this?
>
> Marius Andersen
>
>
>       _________________________________________________________
> Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og
> notisblokk. http://no.mail.yahoo.com
>
>
> _______________________________________________
> implementations-list mailing list
> implementations-list at lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
>   