Re: PATCH: key bindings, fixes, docs, tests for vi stuff

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 21, 11:35am, Oliver Kiddle wrote:
}
} Bart wrote:
} > I have from time to time wondered if segregating some of the builtin
} > widgets into loadable modules might be beneficial.
} 
} This is something I was also pondering. The main obstacle to this, and
} the reason I pulled textobjects inline, relates to keybindings:
} 
} If someone has their bindkey commands early in .zshrc, we don't want
} those to be overridden later when a module gets loaded.  This problem
} already means everyone has to take care to put their listscroll and
} menuselect bindings late in their .zshrc.

Hmm, those seem like two different sides of the coin.  Is it not the
case that the listscroll and menuselect bindings have to be late
because the keymaps don't yet exist?  Thus not because the bindings
would be overridden?  I suppose re-creating the keymap is a form of
override.

But it shouldn't be that difficult to have the modules check for the
existence of the keymap, skip re-creating it it if it's already there,
and then only add bindings that don't conflict?

} As one solution, we could have all default bindings in zle.so. I haven't
} checked what happens if that includes bindings to autoloadable widgets:

Hmm again.  As of right now, I think that would cause the entire module
to load as soon as you attempted to use the binding, which in the case
of e.g. menuselect would re-initialize the keymap and possibly destroy
the binding you just used.

} Do you have any thoughts on what a logical division into modules would
} be? I was thinking along the lines of the vi/emacs split but only for
} those widgets that are unlikely to be used for the opposite mode.

It's difficult to decide.  There are the functional divisions in the
documentation (Movement, History Control, etc.) and then the major
divisions of emacs/vi.

Maybe the way to do it is:

- common default bindings (accept-line, clear-screen, etc.)
- emacs default bindings
- unbound emacs widgets
- vi default bindings
- unbound vi widgets

and then some other modules for miscellaneous stuff that is neither
bound by default, nor really fits into either major editor style
(auto-suffix-retain/remove, read-command, recursive-edit, split-undo,
etc.).  [Maybe there should be a "widgets for use from other widgets"
category.]

} The only existing module: deltochar appears to be mainly there to
} provide an example of doing widgets as a module. Is it a fairly much
} standard thing to an emacs user or is it logical to have it on its own?

I've never used it, but zap-to-char is a standard GNU emacs binding
these days, so perhaps others do.
 
} I also wonder if we could make it possible for shell function widgets
} to specify some sort of default key binding much as is possible for
} completion widgets.

The widgets don't really specify their key binding, that's all done by
compinit when it scans $fpath for #compdef lines.  We could easily have
another such script that looks for a different #something.  There is
already #autoload but it doesn't do bindings.