help / color / mirror / code / Atom feed
From: Roman Perepelitsa <roman.perepelitsa@gmail.com>
To: Ray Andrews <rayandrews@eastlink.ca>
Cc: zsh-users@zsh.org
Subject: Re: key binding not working
Date: Mon, 26 Sep 2022 08:28:13 +0200	[thread overview]
Message-ID: <CAN=4vMq3g1ZAtOphQk+bch_U=DmvJ1YLyO2oSugrkFkJkY409w@mail.gmail.com> (raw)
In-Reply-To: <facd8248-4cd3-8500-d1eb-65b1462f4535@eastlink.ca>

On Mon, Sep 26, 2022 at 3:17 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
> Some config issue I think.
> 'good' version is: " zsh 5.8 (x86_64-pc-none) " ... that's the
> 'non-Debian'.  But if I do:
>      $ zsh -f; . /root/.zshrc
> ... I'm expecting basically an identical result to just:
>      $ zsh
> ... but the latter gives me the working up arrow key and the former does
> not.  So there's some other file being accessed that I don't even know
> is there.  Is there some way of tracing the entire process?

If the non-Debian version is https://github.com/romkatv/zsh-bin, then
you need to keep in mind that it does not read global rc files. This
is a statically built binary, so it has no way of knowing where global
rc files are. Another reason is that I have little respect for global
rc files, including those in Debian.

You can use the following command to list all files sourced by login
interactive zsh, including those sourced from the first precmd and
zle-line-init hooks (if any):

    zsh --sourcetrace -lis <<<exit

If you run that on Debian with the system zsh, you'll see among other
things /etc/zsh/zshrc. If you look inside, you'll find awful things.
Some of them you can disable by defining special parameters in
~/.zshenv, others can only be avoided by turning off global rc
completely. If you decide to keep using global rcs, I highly recommend
adding `skip_global_compinit=1` to ~/.zshenv. If you don't do that,
zsh will start super slow if you change fpath in ~/.zshrc because
zcompdump will be regenerated _twice_ every time you start a new
interactive shell.

There are several ways to make basic keys work in zsh. My favorite is
to translate key codes from other terminals/modes to xterm equivalents
in raw mode and then bind only the latter. Here's an example:

    for 1 in emacs viins vicmd; do
      # If NumLock is off, translate keys to make
      # them appear the same as with NumLock on.
      bindkey -M $1 -s '^[OM'    '^M'      # enter
      bindkey -M $1 -s '^[OX'    '='
      bindkey -M $1 -s '^[Oj'    '*'
      bindkey -M $1 -s '^[Ok'    '+'
      bindkey -M $1 -s '^[Ol'    '+'
      bindkey -M $1 -s '^[Om'    '-'
      bindkey -M $1 -s '^[On'    '.'
      bindkey -M $1 -s '^[Oo'    '/'
      bindkey -M $1 -s '^[Op'    '0'
      bindkey -M $1 -s '^[Oq'    '1'
      bindkey -M $1 -s '^[Or'    '2'
      bindkey -M $1 -s '^[Os'    '3'
      bindkey -M $1 -s '^[Ot'    '4'
      bindkey -M $1 -s '^[Ou'    '5'
      bindkey -M $1 -s '^[Ov'    '6'
      bindkey -M $1 -s '^[Ow'    '7'
      bindkey -M $1 -s '^[Ox'    '8'
      bindkey -M $1 -s '^[Oy'    '9'

      # If someone switches our terminal to application
      # mode (smkx), translate keys to make them appear
      # the same as in raw mode (rmkx).
      bindkey -M $1 -s '^[OA'    '^[[A'    # up
      bindkey -M $1 -s '^[OB'    '^[[B'    # down
      bindkey -M $1 -s '^[OD'    '^[[D'    # left
      bindkey -M $1 -s '^[OC'    '^[[C'    # right
      bindkey -M $1 -s '^[OH'    '^[[H'    # home
      bindkey -M $1 -s '^[OF'    '^[[F'    # end

      # Non-graphical Linux TTY sends different key
      # codes. Translate them to xterm equivalents.
      bindkey -M $1 -s '^[[1~'   '^[[H'    # home
      bindkey -M $1 -s '^[[4~'   '^[[F'    # end

      # Tmux sends different key codes. Translate
      # them to xterm equivalents.
      bindkey -M $1 -s '^[[1~'   '^[[H'    # home
      bindkey -M $1 -s '^[[4~'   '^[[F'    # end
      bindkey -M $1 -s '^[^[[A'  '^[[1;3A' # alt+up
      bindkey -M $1 -s '^[^[[B'  '^[[1;3B' # alt+down
      bindkey -M $1 -s '^[^[[D'  '^[[1;3D' # alt+left
      bindkey -M $1 -s '^[^[[C'  '^[[1;3C' # alt+right
      bindkey -M $1 -s '^[^[[1~' '^[[1;3H' # alt+home
      bindkey -M $1 -s '^[^[[4~' '^[[1;3F' # alt+end
      bindkey -M $1 -s '^[^[[3~' '^[[3;3~' # alt+delete

    # Bind keys with xterm codes.
    bindkey -M emacs '^[[H' beginning-of-line     # home
    bindkey -M viins '^[[H' vi-beginning-of-line  # home
    bindkey -M emacs '^[[F' end-of-line           # end
    bindkey -M viins '^[[F' vi-end-of-line        # end

(It should read better with a monospace font.)

I lifted this code from
You can find more bindings in there. This code in turn was lifted from

The two common objections to binding keys this way are clashes and
performance. Neither applies in practice: there are no clashes and
virtually no performance impact on zsh startup time. On my machine the
code I posted above takes about 10 times less time to evaluate than
invoking /bin/true.


  parent reply	other threads:[~2022-09-26  6:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25 21:14 Ray Andrews
2022-09-25 22:31 ` Bart Schaefer
2022-09-25 22:46   ` Ray Andrews
2022-09-25 23:14     ` Ray Andrews
2022-09-26  3:48     ` Marc Chantreux
2022-09-27  0:30     ` zkbd (was Re: key binding not working) Bart Schaefer
2022-09-27  1:39       ` Ray Andrews
2022-09-26  1:16   ` key binding not working Ray Andrews
2022-09-26  1:58     ` Lawrence Velázquez
2022-09-26  3:15       ` Ray Andrews
2022-09-26  4:01         ` Lawrence Velázquez
2022-09-26  6:28     ` Roman Perepelitsa [this message]
2022-09-26 13:59       ` key binding not working [SOLVED] Ray Andrews
2022-09-26 18:04         ` Ray Andrews
2022-09-26 18:13           ` Roman Perepelitsa
2022-09-26 19:12             ` Peter Stephenson
2022-09-26 19:43               ` Mikael Magnusson
2022-09-26 21:31             ` Ray Andrews
2022-09-26 22:27               ` Vin Shelton
2022-09-26 22:35                 ` Ray Andrews

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='CAN=4vMq3g1ZAtOphQk+bch_U=DmvJ1YLyO2oSugrkFkJkY409w@mail.gmail.com' \
    --to=roman.perepelitsa@gmail.com \
    --cc=rayandrews@eastlink.ca \
    --cc=zsh-users@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).