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

[Vadim Zeitlin]

On Fri, 25 Oct 2019 02:17:53 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-10-24 21:50, Vadim Zeitlin wrote:
GC> > On Thu, 24 Oct 2019 18:59:28 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> The intention is just to color $PROMPT based on zle $KEYMAP.
GC> > GC>     
GC> > GC> That intention is accomplished, but with a distressing side effect:
GC> > GC> the Home and End keys no longer work as desired.
GC> > 
GC> >  My initial reaction was to say that it was impossible, but as it
GC> > nevertheless happens to you, I've tried to do as Holmes would have done 
and
GC> > deduce a possible explanation. Unfortunately the only thing I could come 
up
GC> > is this: defining your custom zle-line-init widget must have overwritten
GC> > the previous definition of this widget used by zsh which made these keys
GC> > work. This explanation fits all the observable data, so it must be true,
GC> > right?
GC> 
GC> The same argument has been made for superstring theory; but your
GC> hypothesis is testable.

 Some really smart people work on superstring theory. I'm not clever enough
to make theories sufficiently complicated to be untestable at our
civilization technology level. Even if I hoped that bringing in terminfo
stuff would take us at least halfway there.

GC> The identically-defined {zle-line-init, zle-keymap-select} functions
GC> weren't my original idea (I adapted them from stuff I found online).
GC> Removing the zle-line-init function does solve the {Home,End} problem.
GC> However, it exposes other issues that the dual function definition
GC> was probably intended to solve:
GC> 
GC> (1) When I start a zsh session, say by entering a chroot:
GC> 
GC>   /tmp[0]$schroot --chroot=chroot:bullseye0
GC>   ugolyok% 
GC> 
GC> the initial prompt is "${hostname}% ".

 This could be trivially fixed by defining the prompt to the value used in
your functions in .zshrc. In fact, I don't like the way these functions are
written: IMO, the prompt should be defined in PS1 and the function should
just either add the escape sequences around it (in "vicmd" case) or strip
them otherwise. Delegating the prompt definition to zle-line-init just
doesn't seem right.

GC> I could live with that; but...
GC> 
GC> (2) Then, when I hit Esc to enter vicmd mode, the prompt stays in
GC> that mode, even after I hit Enter to execute a command:
GC> 
GC>   /tmp[0]$-vicmd-$ls >/dev/null
GC>   /tmp[0]$-vicmd-$

 You're right, fixing this does require doing something in either
zle-line-init or zle-line-finish. I didn't think of the case in which the
line is accepted in vi command mode.

GC> I also tried switching the order of the functions:
GC> 
GC> -function zle-line-init zle-keymap-select {
GC> +function zle-keymap-select zle-line-init {
GC> -zle -N zle-line-init
GC> -zle -N zle-keymap-select
GC> +zle -N zle-keymap-select
GC> +zle -N zle-line-init
GC> 
GC> but that made no difference.

 Why should it have? At least this one thing doesn't seem surprising at all
to me.

GC> > - Or check what does the existing widget do, by doing "echo
GC> >   $widgets[zle-line-init]", and then do the same thing in your 
replacement.
GC> >   E.g. here the default widget happens to be defined by zle-line-init
GC> >   function which does "printf '%s' ${terminfo[smkx]}" (I'll let you dig
GC> >   through terminfo manual if you want to know what smkx does entirely, but
GC> >   be warned that it's not very exciting) per its definition in
GC> >   /etc/zsh/zshrc on Debian systems.
GC> 
GC> Running that command first in my host system (where I've never defined
GC> any such function), and then in the chroot (where I do define them):
GC> 
GC> /tmp[0]$echo $widgets[zle-line-init]     
GC> user:zle-line-init
GC> /tmp[0]$schroot --chroot=chroot:bullseye0
GC> /tmp[0]$-main-$echo $widgets[zle-line-init]
GC> user:zle-line-init
GC> 
GC> the output is the same--and different from yours.

 Sorry, it's the same, I've just skipped a step. The above shows that
zle-line-init ZLE widget is bound to user-defined zle-line-init function.
So now you can use "where zle-line-init" to see that this function sends
"smkx" terminfo sequence to the terminal.

GC> The motivating problem is that
GC>  - when editing files in vim, I rely on "-- INSERT --" at the bottom
GC>    of the screen to tell me what mode I'm in;
GC>  - in zsh's vim mode, I never know what $KEYMAP I'm using, and I get
GC>    confused too easily, so I want a visual indication.
GC> Do you know a better way to solve that problem? Is it a problem that
GC> you just don't have, because you're always aware what mode you're in?

 I've never asked myself this question before, so I guess this means that I
am. Unlike some other people I do _not_ switch to vicmd mode in
zle-line-init, so I'm basically always in normal mode except when I
briefly temporarily switch to vicmd to perform some commands like "c2w" or
something like that. I.e. I know which mode I'm in because I'm always in
normal mode except when I've just done something to switch to vicmd mode.
And I always switch back to normal mode immediately afterwards, i.e. if I
use some command not switching to insert mode on its own (like "c" does),
e.g. if I do "f[", I usually press "i" or "a" immediately anyhow.

 This is quite different from the way I use Vim, where I can remain in
either mode for longer periods of time, so while I do remember finding the
"-- INSERT --" prompt Vim useful (although I have to admit that I don't
notice it any more since quite a long time too), I've just never had this
problem with the command line editing.

GC> >  In any case, I'm pretty sure you should be able to resolve the issue by
GC> > explicitly binding whatever code these keys generate for you (which really
GC> > should be the same ones as here, i.e. "<Esc>[1~" and "<Esc>[4~") to the
GC> 
GC> /tmp[0]$echo "${terminfo[khome]}" |od -t a
GC> 0000000 esc   O   H  nl
GC> 0000004
GC> /tmp[0]$echo "${terminfo[kend]}" |od -t a
GC> 0000000 esc   O   F  nl
GC> 0000004
GC> 
GC> It seems odd that mine don't match yours.
[...]
GC> This suggests new hypotheses: that the terminal is responsible;

 You're absolutely right, our terminals have different terminfo entries, so
this definitely explains this discrepancy.

GC> > corresponding widgets, but I'm afraid I can't convincingly explain why do
GC> > you see what you're seeing. But maybe just fixing it would be enough?
GC> 
GC> ...so, yes, that's plenty good enough.

 I'm relieved to hear this because life is just too short to master all the
terminfo mysteries.

 Best regards,
VZ

pgp0ITUxlQG3F.pgp
Description: PGP signature