help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: setopt emacs / vi again
Date: Mon, 6 Mar 2023 14:44:05 -0800	[thread overview]
Message-ID: <CAH+w=7ZC8s+oM4KK8as+oYOU9qg=CN2CmSQim0+Ptf=x_tiJww@mail.gmail.com> (raw)

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.

                 reply	other threads:[~2023-03-06 22:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7ZC8s+oM4KK8as+oYOU9qg=CN2CmSQim0+Ptf=x_tiJww@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).