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

[Marius Andersen]

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