lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Chicares
Subject: Re: [lmi] Failed vim-mode .zshrc experiment
Date: Fri, 25 Oct 2019 18:21:28 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 2019-10-25 14:53, Vadim Zeitlin wrote:
> 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:

[...definitions of zle-line-init and zle-keymap-select...]

> [...] 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.

I tried zsh parameter substitution, with no functions, e.g.:

  local_prompt='%d[%?]%(!.#.$)'
  
PS1="${${KEYMAP/vicmd/%F{yellow}${local_prompt}%f}/(main|viins)/${local_prompt}}"

but that can't work because $KEYMAP is internal to ZLE. But that's
not what you recommended--you propose defining $PS1 globally, and
then using the functions to modify it. Here's how I've experimentally
implemented that:

prompt='%d[%?]%(!.#.$)'

function zle-line-init zle-keymap-select {
    if [[ ${KEYMAP} == vicmd ]]; then
        prompt="%F{yellow}${prompt}%f"
    else
        prompt="${${prompt##%F{yellow\}}%%%f}"
    fi
    zle reset-prompt
}

zle -N zle-line-init
zle -N zle-keymap-select

IMO that's drastically worse. I arrived at that through experimentation,
but one minute later I can't understand it. Apparently '%' is quoted by
doubling it, though the resulting '%%%' isn't easy to parse: does it
remove a maximal (%%) initial substring beginning with '%', or does it
remove a minimal (%) initial substring beginning with a '%'-quoted '%'?
But wait--the quoting rule for '}' is different: it requires a '\'.

And even if this were comprehensible and maintainable, it still seems
fragile. What does the prompt become if we paste the following line
into the terminal?
  prompt="abc%F{red}%F{yellow}%f%fxyz$"

Did you have a cleaner implementation in mind?

> 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

But doesn't vim's "normal mode" correspond to zsh's vicmd mode,
so that typing 'x' deletes a character instead of inserting the
character between 'w' and 'y' in the latin alphabet?

AIUI, anyone who makes vicmd mode the default for every new line
would have to type
  ils
to run the 'ls' command, using 'i' to activate the viins keymap.
People really do that?

> 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.

Okay, this makes sense to me if I read "normal" as viins.

>  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.

Okay, maybe things like "-- INSERT --" and my prompt coloring are
temporary learning aids that become unnecessary after a while.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]