trouble with vimbindings...

trouble with vimbindings...

[iamjay]

Hey all..

I'm having a bit of an issue.. which also occured when starting zsh with
-f...

When using vimkeybindings with bindkey -v... and you create a laaaarge
command like:

echo foo barfoo barfoo barfoo barfoo barfoo barfoo barfoo bar \
 foo bar bar barba rbar b barb bar



and you leave vim's insert mode.. theres no way for me to go to the
upper line.. I tried gj gk... but those keep pushing the history on the
second line for- and backwards...

Am I doing something wrong here?

Thanks in advance!

Best regards,

Joerg

Re: trouble with vimbindings...

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On 15 марта 2009 23:56:30 iamjay wrote:
> Hey all..
>
> I'm having a bit of an issue.. which also occured when starting zsh
> with -f...
>
> When using vimkeybindings with bindkey -v... and you create a
> laaaarge command like:
>
> echo foo barfoo barfoo barfoo barfoo barfoo barfoo barfoo bar \
>  foo bar bar barba rbar b barb bar
>
>
>
> and you leave vim's insert mode.. theres no way for me to go to the
> upper line.. I tried gj gk... but those keep pushing the history on
> the second line for- and backwards...
>

Works for me with k. Why would you want to use gk?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: trouble with vimbindings...

[iamjay]

Really its working??? Huh... whats the problem for me then... :(
Shouldnt zsh -f put EVERYTHING off??
I dunno I thought I had to use gj gk... because j, k weren't working...

On Mon, Mar 16, 2009 at 12:09:54AM +0300, Andrey Borzenkov wrote:
> On 15 марта 2009 23:56:30 iamjay wrote:
> > Hey all..
> >
> > I'm having a bit of an issue.. which also occured when starting zsh
> > with -f...
> >
> > When using vimkeybindings with bindkey -v... and you create a
> > laaaarge command like:
> >
> > echo foo barfoo barfoo barfoo barfoo barfoo barfoo barfoo bar \
> >  foo bar bar barba rbar b barb bar
> >
> >
> >
> > and you leave vim's insert mode.. theres no way for me to go to the
> > upper line.. I tried gj gk... but those keep pushing the history on
> > the second line for- and backwards...
> >
> 
> Works for me with k. Why would you want to use gk?

Re: trouble with vimbindings...

[Bart Schaefer]

On Mar 15,  9:56pm, iamjay wrote:
}
} When using vimkeybindings with bindkey -v... and you create a laaaarge
} command like:
} 
} echo foo barfoo barfoo barfoo barfoo barfoo barfoo barfoo bar \
}  foo bar bar barba rbar b barb bar
} 
} and you leave vim's insert mode.. theres no way for me to go to the
} upper line..

This is the way the line editor always works.  When you hit enter
at the end of the First line, the editor finishes and passes the
line to the parser, which finds the backslash and starts up a new
editor for the second line.  (This is true in emacs mode as well.)

So leaving insert mode while editing the second line leaves you in
the same instance of the editor which "contains" only that second
line.

There are several ways to "fix" this.  One would be to override the
accept-line widget so that you never leave the first editor:

    backslash-accept-line() {
      # Consider replacing LBUFFER with BUFFER on the next two
      # lines, depending on your preferred semantics
      if [[ $LBUFFER = *\\ ]]
      then LBUFFER+=$'\n'
      else zle .accept-line "$@"
      fi
    }
    zle -N accept-line backslash-accept-line

The above doesn't handle the general case of multi-line constructs.
For that you need something more violent:

    init-cmd-mode() {
      # Needs adjustment if you otherwise define zle-line-init
      zle -D zle-line-init
      zle .vi-cmd-mode
      zle -R
    }
    vi-cmd-mode() {
      if [[ -n "$PREBUFFER" ]]
      then
        # Needs adjustment if you otherwise define zle-line-init
        zle -N zle-line-init init-cmd-mode
	zle push-line-or-edit
      else
        zle .vi-cmd-mode "$@"
      fi
    }
    zle -N vi-cmd-mode

Using push-line-or-edit effectively says "kill this editor and start
a new one with the entire multi-line command I was working on."  The
init-cmd-mode trick is needed to propagate the last command from the
editor that's being killed, into the new editor that's starting up.

Other solutions are also possible, but I'm not going to try to invent
all of them ...

Re: trouble with vimbindings...

[iamjay]

Thanks!
That solves my problem...
Just wondering why it isn't implemented that way by default...
well nevermind

Best regards,

On Sun, Mar 15, 2009 at 03:01:37PM -0700, Bart Schaefer wrote:
> On Mar 15,  9:56pm, iamjay wrote:
> }
> } When using vimkeybindings with bindkey -v... and you create a laaaarge
> } command like:
> } 
> } echo foo barfoo barfoo barfoo barfoo barfoo barfoo barfoo bar \
> }  foo bar bar barba rbar b barb bar
> } 
> } and you leave vim's insert mode.. theres no way for me to go to the
> } upper line..
> 
> This is the way the line editor always works.  When you hit enter
> at the end of the First line, the editor finishes and passes the
> line to the parser, which finds the backslash and starts up a new
> editor for the second line.  (This is true in emacs mode as well.)
> 
> So leaving insert mode while editing the second line leaves you in
> the same instance of the editor which "contains" only that second
> line.
> 
> There are several ways to "fix" this.  One would be to override the
> accept-line widget so that you never leave the first editor:
> 
>     backslash-accept-line() {
>       # Consider replacing LBUFFER with BUFFER on the next two
>       # lines, depending on your preferred semantics
>       if [[ $LBUFFER = *\\ ]]
>       then LBUFFER+=$'\n'
>       else zle .accept-line "$@"
>       fi
>     }
>     zle -N accept-line backslash-accept-line
> 
> The above doesn't handle the general case of multi-line constructs.
> For that you need something more violent:
> 
>     init-cmd-mode() {
>       # Needs adjustment if you otherwise define zle-line-init
>       zle -D zle-line-init
>       zle .vi-cmd-mode
>       zle -R
>     }
>     vi-cmd-mode() {
>       if [[ -n "$PREBUFFER" ]]
>       then
>         # Needs adjustment if you otherwise define zle-line-init
>         zle -N zle-line-init init-cmd-mode
> 	zle push-line-or-edit
>       else
>         zle .vi-cmd-mode "$@"
>       fi
>     }
>     zle -N vi-cmd-mode
> 
> Using push-line-or-edit effectively says "kill this editor and start
> a new one with the entire multi-line command I was working on."  The
> init-cmd-mode trick is needed to propagate the last command from the
> editor that's being killed, into the new editor that's starting up.
> 
> Other solutions are also possible, but I'm not going to try to invent
> all of them ...

Re: trouble with vimbindings...

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On 16 марта 2009 01:01:37 Bart Schaefer wrote:
> On Mar 15,  9:56pm, iamjay wrote:
> }
> } When using vimkeybindings with bindkey -v... and you create a
> laaaarge } command like:
> }
> } echo foo barfoo barfoo barfoo barfoo barfoo barfoo barfoo bar \
> }  foo bar bar barba rbar b barb bar
> }
> } and you leave vim's insert mode.. theres no way for me to go to the
> } upper line..
>
> This is the way the line editor always works.  When you hit enter
> at the end of the First line, the editor finishes and passes the
> line to the parser, which finds the backslash and starts up a new
> editor for the second line.  (This is true in emacs mode as well.)
>
> So leaving insert mode while editing the second line leaves you in
> the same instance of the editor which "contains" only that second
> line.
>

I misunderstood the issue, sorry.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: trouble with vimbindings...

[Bart Schaefer]

On Mar 16,  1:04am, iamjay wrote:
} Subject: Re: trouble with vimbindings...
}
} Thanks!
} That solves my problem...
} Just wondering why it isn't implemented that way by default...

You just need to remember that zsh has been around for almost 20 years,
and nearly everything it does is layered on top of something that it
originally did slightly differently.

Before there was a line editor, there was a parser.  The parser was the
best way to figure out whether the shell had a complete command to be
executed, or whether it needed to print the PS2 prompt and read further;
but to invoke the parser you had to process the current input line.

Before the line editor could handle multiple lines, there was a line
editor that could deal only with moving left and right within a single
line; so there wasn't any need to keep earlier lines around once they
were passed through the parser.