Excerpts from Jean-Philippe Bernardy's message of Tue Jul 22 22:36:26 +0200 2008: > > This seems overkill to me: it looks like reconstructing the top-level > keymap is only one line of code > provided we export the proper things. Do I miss something?
That's one line of code extend the command mode (the initial one), but the
insert
mode is behind some keymaps like 'i' (insert). So one can't extend it.
Cheers,
> On Tue, Jul 22, 2008 at 6:46 PM, Corey O'Connor <[EMAIL PROTECTED]> wrote:
> >
> > Suppose I'd like to extend the Vim keymap's insert mode, but I'd like
> > to do so in a user-specific manner. Seems like I cannot do so with the
> > current implementation: it's fairly easy to add a new choice to the
> > cmd_mode interact process, but adding to just the insert mode keymap
> > would be difficult.
> >
> > One implementation that would allow, hopefully, easy extension of each
> > mode's keymap is: Defining the vim keymap be a product of a data
> > structure which contains a field defining each mode's keymap. EG:
> > (In Yi/Keymap/Vim.hs)
> > keymap = makeVimKeymap defKeymapConfig
> >
> > Which would hopefully allow config-like customization of the Vim
> > keymap in the user's yi.hs. Something like:
> >
> > keymap = defKeymapConfig { insModeKeymap = myCustomAction <||
> > (insModeKeymap defKeymapConfig) }
> >
> > An extension of which would be to create a framework for adding new modes.
> >
> > Does this sound reasonable? Or is there something I'm missing that
> > would simplify this?
> >
> > --
> > -Corey O'Connor
> >
> > >
> >
>
--
Nicolas Pouillard aka Ertai
signature.asc
Description: PGP signature
