setopt emacs / vi again

setopt emacs / vi again

[Bart Schaefer]

Back in workers/50729, Jun T wrote:
> Use of EMACS/VI should be highly discouraged, since turning them off
> has no effect, and they are meaningless if a user-defined keymap
> is in use.

There was a subsequent patch in workers/50851 that includes some doc updates:

> item(tt(EMACS))(
>  If ZLE is loaded, turning on this option has the equivalent effect
> +of `tt(bindkey -e)'.  In addition, the tt(VI) option is unset.
>  Turning it off has no effect.  The option setting is
> +not guaranteed to reflect the current keymap, and the tt(LOCALOPTIONS)
> +option does not work correctly. This option is provided only for
> +compatibility, and its use is highly discouraged.  tt(bindkey) is the
> +recommended interface.
> )

and similar wording for setopt vi, along with some code changes so
that bindkey commands force the option settings to match the selected
main keymap.  (It's still a bit of a shortcoming that there is no way
to query which keymap is currently linked.)

> In doshfunc() we can't tell to which keymap we should link the 'main'
> keymap because both EMACS and VI may be off in the saved opts[].

As is probably obvious from recent patches, I've been noodling around
with ksh93, and consequently I re-discovered the origin of the emacs
and vi setopts:  ksh has

set -o vi
set -o emacs
set -o gmacs

(the latter probably more recent than the zsh attempt to copy them).
The key point in relation to the zsh options is that, in ksh93, if
none of these options is set, then line editing is completely disabled
-- the zsh equivalent of "unsetopt zle".  There's no question of which
keymap to link, because there isn't any keymap at all.

I'm not suggesting that we actually do this in zsh -- I think the
current state is likely the best we can do.  However, if we again
discuss deprecating these setopts, it may be useful to know where they
came from and how they affect ksh emulation.