Re: [lmi] Failed vim-mode .zshrc experiment

[Vadim Zeitlin]

On Thu, 24 Oct 2019 18:59:28 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--When convenient, would you please look at new branch odd/zsh_vim,
GC> which has only one commit? I can't understand the behavior described,
GC> and I'm hoping you'll quickly spot some obvious mistake.

 Hi,

 I learnt something new today: I had no idea you could use "function foo
bar { ... }" to define 2 functions with different names with the same body.
But this is not a mistake, of course, just something I found a bit unusual.

GC> Commit message:
GC> 
GC> The intention is just to color $PROMPT based on zle $KEYMAP.
GC>     
GC> That intention is accomplished, but with a distressing side effect:
GC> the Home and End keys no longer work as desired.

 My initial reaction was to say that it was impossible, but as it
nevertheless happens to you, I've tried to do as Holmes would have done and
deduce a possible explanation. Unfortunately the only thing I could come up
is this: defining your custom zle-line-init widget must have overwritten
the previous definition of this widget used by zsh which made these keys
work. This explanation fits all the observable data, so it must be true,
right?

 The only problem with this beautiful theory is that it doesn't work for
me: both because your ZLE widgets changes don't break Home/End for me, and
because they work for me in the first place only because I have custom
bindings for them. Moreover, I've just created a new user just for testing
and, even without any .zshrc, your custom ZLE widgets still work and don't
break Home/End for me. So this is probably not the right explanation, after
all, but I just have no idea what else could it be, so I'm offering what I
have.

 In case this explanation is somehow correct, I can offer two possible
solutions:

- Either stop defining zle-line-init widget, as it doesn't seem necessary:
  in my, admittedly limited, testing, defining just zle-keymap-select seems
  to be enough and to work as intended.

- Or check what does the existing widget do, by doing "echo
  $widgets[zle-line-init]", and then do the same thing in your replacement.
  E.g. here the default widget happens to be defined by zle-line-init
  function which does "printf '%s' ${terminfo[smkx]}" (I'll let you dig
  through terminfo manual if you want to know what smkx does entirely, but
  be warned that it's not very exciting) per its definition in
  /etc/zsh/zshrc on Debian systems.

 The nice thing is that applying one of those solutions might solve the
problem even if my explanation is wrong, so why not try them?


GC> With this commit, neither Home nor End moves the cursor as expected.
GC> Instead, Home enters 'vicmd' mode, and End followed by right-arrow
GC> deletes to end of line.

 You can try entering "^V" (<Ctrl-V>) and then "Home" to see what escape
sequence this key generates for you. Here it generates "^[[1~", i.e.
"<Esc>[1~", and I have

        bindkey "^[[1~" beginning-of-line

in my .zshrc (all the characters in the line above are simple ASCII
characters and not a representation of unprintable characters). This line
has been in my .zshrc ever since I put it under version control 15 years
ago, so I don't remember why did I have to add it. Maybe zsh didn't set it
up correctly back then when using vi mode (as one of the first lines in my
.zshrc is "bindkey -v", of course). Nowadays it seems that Home/End are
bound to vi-{beginning,end}-of-line by default in vi mode, which should be
just fine, but maybe you have some non-default bindings for them somehow?

 In any case, I'm pretty sure you should be able to resolve the issue by
explicitly binding whatever code these keys generate for you (which really
should be the same ones as here, i.e. "<Esc>[1~" and "<Esc>[4~") to the
corresponding widgets, but I'm afraid I can't convincingly explain why do
you see what you're seeing. But maybe just fixing it would be enough?

 Good luck,
VZ

pgpKxR0WQkXXk.pgp
Description: PGP signature