Loading ...
Sorry, an error occurred while loading the content.

Re: mappings time out bug?

Expand Messages
  • Liang Li
    ... [ x]gp Just like p , but leave the cursor just after the new text. {not in Vi} -- -- You received this message from the vim_use maillist. Do not
    Message 1 of 8 , Jun 19, 2013
    • 0 Attachment
      On Wednesday, June 19, 2013 5:19:06 AM UTC-4, ZyX wrote:
      > On Jun 19, 2013 1:13 PM, "Liang Li" <q33...@...> 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}

      --
      --
      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@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Nikolay Pavlov
      ... 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. ... command gp.
      Message 2 of 8 , Jun 19, 2013
      • 0 Attachment


        On Jun 19, 2013 1:37 PM, "Liang Li" <q335r49@...> wrote:
        >
        > On Wednesday, June 19, 2013 5:19:06 AM UTC-4, ZyX wrote:
        > > On Jun 19, 2013 1:13 PM, "Liang Li" <q33...@...> 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).

        > --
        > --
        > 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@....
        > 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@....
        For more options, visit https://groups.google.com/groups/opt_out.
         
         
      • Liang Li
        ... 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
        Message 3 of 8 , Jun 19, 2013
        • 0 Attachment
          On Wednesday, June 19, 2013 5:42:06 AM UTC-4, ZyX wrote:
          > On Jun 19, 2013 1:37 PM, "Liang Li" <q33...@...> wrote:
          >
          > >
          >
          > > On Wednesday, June 19, 2013 5:19:06 AM UTC-4, ZyX wrote:
          >
          > > > On Jun 19, 2013 1:13 PM, "Liang Li" <q33...@...> 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.

          --
          --
          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@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Nikolay Pavlov
          ... 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. ... normal
          Message 4 of 8 , Jun 19, 2013
          • 0 Attachment


            On Jun 19, 2013 1:48 PM, "Liang Li" <q335r49@...> wrote:
            >
            > On Wednesday, June 19, 2013 5:42:06 AM UTC-4, ZyX wrote:
            > > On Jun 19, 2013 1:37 PM, "Liang Li" <q33...@...> wrote:
            > >
            > > >
            > >
            > > > On Wednesday, June 19, 2013 5:19:06 AM UTC-4, ZyX wrote:
            > >
            > > > > On Jun 19, 2013 1:13 PM, "Liang Li" <q33...@...> 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@....
            > 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@....
            For more options, visit https://groups.google.com/groups/opt_out.
             
             
          • John Beckett
            Has this issue been sorted out? Let s not work out who-said- what. ... My thoughts are that by default, and as per :help gp , there is no gp mapping, so you
            Message 5 of 8 , Jun 19, 2013
            • 0 Attachment
              Has this issue been sorted out? Let's not work out who-said-
              what.

              The OP was:

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

              My thoughts are that by default, and as per ":help gp", there
              is no gp mapping, so you can press g, then wait a minute, then
              press p (no timeout).

              However, once you have a mapping (the nnoremap above), the
              situation is completely changed. The timeout does apply to the
              mapping, and you would have to type gp quickly for the g to have
              any effect.

              John


              --
              --
              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@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Liang Li
              ... I think I overreacted on a rather minor issue which is probably the norm for these semi-anonymous online issues and for someone as anal as I mam. It s
              Message 6 of 8 , Jun 19, 2013
              • 0 Attachment
                On Wednesday, June 19, 2013 7:39:26 AM UTC-4, JohnBeckett wrote:
                > Has this issue been sorted out? Let's not work out who-said-
                >
                > what.
                >
                >
                >
                > The OP was:
                >
                >
                >
                > > 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.
                >
                >
                >
                > My thoughts are that by default, and as per ":help gp", there
                >
                > is no gp mapping, so you can press g, then wait a minute, then
                >
                > press p (no timeout).
                >
                >
                >
                > However, once you have a mapping (the nnoremap above), the
                >
                > situation is completely changed. The timeout does apply to the
                >
                > mapping, and you would have to type gp quickly for the g to have
                >
                > any effect.

                I think I overreacted on a rather minor issue which is probably the norm for these semi-anonymous online issues and for someone as anal as I mam. It's quirky behavior that's mostly undocumented but it confused me and I spent a long time trying to figure it out, and this process of figuring it out did not seem all that rewarding. To me, it sounds like you are defending vim for wasting my time, but of course there are other perspectives as well :-D

                I'd be content with letting this rest, it will probably go on to confuse future generations. There is an easy fix of course, something along the lines of:

                nnoremap g :call MyGFunction()
                fun! MyGFunction
                let c=getchar()
                if c==char2nr('p')
                norm! `[v]`
                else
                exe 'norm! g'.c
                en
                endfun

                --
                --
                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@....
                For more options, visit https://groups.google.com/groups/opt_out.
              Your message has been successfully submitted and would be delivered to recipients shortly.