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

[Oliver Kiddle <okiddle@yahoo.co.uk>]

Bart wrote:
> } + * textobjects.c - ZLE module implementing Vim style text objects
> 
> This isn't actually a "module" is it?  It's just part of the ZLE vi
> widget set?

Yes. It was when I wrote that text.

> 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.

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:
(i.e. if it is possible and if so whether that results in instant or
deferred loading). I wouldn't want a module for execute-named-cmd loaded
just because I want to bind a few keys in the command keymap but I'd
want the keymap to be there.

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.
We might also have a few smaller modules, e.g. for execute-named-cmd. I
use a shell function replacement that uses read-from-minibuffer.

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 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. For text objects I was going to mostly use shell
functions. Of the two existing ones, shell-word needs the lexer and
basic words are sort of fundamental. I've perhaps made them more vim
compatible than was necessary except where the vim behaviour looks like
a bug (successive newlines and the first character in the buffer).

Oliver