Re: mappings time out bug?

On Jun 19, 2013 1:48 PM, "Liang Li" <q335r49@gmail.com> wrote:
>
> On Wednesday, June 19, 2013 5:42:06 AM UTC-4, ZyX wrote:
> > On Jun 19, 2013 1:37 PM, "Liang Li" <q33...@gmail.com> wrote:
> >
> > >
> >
> > > On Wednesday, June 19, 2013 5:19:06 AM UTC-4, ZyX wrote:
> >
> > > > On Jun 19, 2013 1:13 PM, "Liang Li" <q33...@gmail.com> wrote:
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > This behavior confuses me. It feels like a bug.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > I have the following mapping
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > nnoremap gp `[v`]
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > since 'g' is not mapped, it shouldn't timeout no matter what the timeout length is right? As expected, the built in mapping for gp, gv, etc. both work no matter how long one waits between the g and the p.
> >
> >
> > > >
> >
> > > >
> >
> > > > Wrong. There is no built-in mappings like gp. More, there is no normal command gp. What is being done there is invocation of the getchar-like function after pressing g. Think of it as a special submode: enter-g-command-tail.
> >
> >
> > >
> >
> > > :help gp
> >
> > >
> >
> > > ["x]gp                  Just like "p", but leave the cursor just after the new
> >
> > >                         text.  {not in Vi}
> >
> > Don't point me to help. Take vim source code and look there. **There** is no gp mapping. There *is* code catching 'g' and using blocking read via getchar-like function to get next character ('p' in this case).
>
> Thanks for friendly welcome.
>
> You just basically explained, I suppose, why there is a bug. That doesn't make it less of a bug. If I say, "Hey, this program crashes when I press the 'Q' key", you can say, "Well, when you press the Q key it divides by zero. That's expected behavior when one divides by zero." ...hmmmm...
>
> The fact is that if I remap gp, after the timeout it triggers the 'predefined' gp, rather than the expected behavior of triggering my remapping. The fact that this is unexpected behavior makes it a bug.

Please point to a line in the help showing that built-in normal commands are mappings. Or where it states that Vim must wait for more input in your case. There are (partly documented) architecture and implementation problems in vim input processing system and you have just touched one of it.

It indeed is unexpected behavior (I do not think current behavior can be deduced from help) and strange implementation: if I already had mappings, especially multiple mappings containers with one (buffer-local) having priority over another (global) I would have just added the third layer with lowest priority (built-in commands). But it is not as bad as a crash.

Also note the direction of discussion:

1. you said gp is a mapping (among other statements)
2. I then said you are wrong on *this* point (*without* commenting the main complaint about unexpected behavior)
3. you pointed to help (looked for me like trying to disproof my statement about no gp mapping)
4. I pointed out that I am talking about implementation

There was *no* discussion of the validity of the main point from my side, only discussion about the validity of the "gp is a mapping" statement.

> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
 
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.