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

Behaviour of :normal in operator-pending mode is not defined

Expand Messages
  • glts
    While investigating an item on the todo list, I found out that the behaviour of :normal[!] in operator-pending mode is not well-defined: it is not documented
    Message 1 of 4 , Mar 6, 2013
    • 0 Attachment
      While investigating an item on the todo list, I found out that the
      behaviour of :normal[!] in operator-pending mode is not well-defined: it
      is not documented and is not taken special care of in the source.

      Consider the following text with the cursor on the first "m":

      summer
      ^

      Then consider these commands and the results:

      gUe suMMER
      :norm! gUe<CR> suMMER
      gU:norm! e<CR> suMMEr

      gUiw SUMMER
      :norm! gUiw<CR> SUMMER
      gU:norm! iw<CR> suwmmer

      For gU as for all operators the behaviour is strange and inconsistent.
      There's a design decision to be made. Two possibilities:

      1. :normal[!] stops operator-pending mode, then executes normal mode
      commands.
      2. :normal[!] takes operator-pending mode into account when it begins
      executing normal mode commands.

      --
      --
      You received this message from the "vim_dev" 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_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ben Fritz
      ... I don t see anything wrong here. From normal mode, iw does not mean select the inner word , it means insert a w character . In operator-pending mode
      Message 2 of 4 , Mar 7, 2013
      • 0 Attachment
        On Wednesday, March 6, 2013 4:43:56 PM UTC-6, glts wrote:
        > While investigating an item on the todo list, I found out that the
        >
        > behaviour of :normal[!] in operator-pending mode is not well-defined: it
        >
        > is not documented and is not taken special care of in the source.
        >
        >
        >
        > Consider the following text with the cursor on the first "m":
        >
        >
        >
        > summer
        >
        > ^
        >
        >
        >
        > Then consider these commands and the results:
        >
        >
        >
        > gUe suMMER
        >
        > :norm! gUe<CR> suMMER
        >
        > gU:norm! e<CR> suMMEr
        >

        I'm not sure if this is documented (I couldn't find it mentioned explicitly) but if I recall correctly, any : command in operator-pending mode acts as an exclusive motion. You can force it to be inclusive using v before the : in your command. See:

        :help inclusive
        :help o_v

        >
        > gUiw SUMMER
        > :norm! gUiw<CR> SUMMER
        > gU:norm! iw<CR> suwmmer
        >
        > For gU as for all operators the behaviour is strange and inconsistent.
        >

        I don't see anything wrong here. From normal mode, "iw" does not mean "select the inner word", it means "insert a w character". In operator-pending mode you're just trying to move the cursor, not do insertions. If you want the last one to work you should have done something that in normal mode would move the cursor without side effects, such as viw, not something that only inserts text and doesn't move the cursor.

        --
        --
        You received this message from the "vim_dev" 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_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • glts
        I see. I was thinking about it the wrong way then. ... Yes, I did see that in the code for the colon command at normal.c#5398: if (cap- oap- op_type != OP_NOP)
        Message 3 of 4 , Mar 7, 2013
        • 0 Attachment
          I see. I was thinking about it the wrong way then.

          On Thursday, March 7, 2013 5:35:24 PM UTC+1, Ben Fritz wrote:
          > > gUe suMMER
          > > :norm! gUe<CR> suMMER
          > > gU:norm! e<CR> suMMEr
          >
          > I'm not sure if this is documented (I couldn't find it mentioned
          > explicitly) but if I recall correctly, any : command in operator-pending
          > mode acts as an exclusive motion.

          Yes, I did see that in the code for the colon command at normal.c#5398:

          if (cap->oap->op_type != OP_NOP)
          {
          /* Using ":" as a movement is characterwise exclusive. */
          cap->oap->motion_type = MCHAR;
          cap->oap->inclusive = FALSE;
          }

          I added a note in the documentation and removed a now invalid item from
          the todo list.

          David Bürgin

          --
          --
          You received this message from the "vim_dev" 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_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Bram Moolenaar
          ... Thanks! -- hundred-and-one symptoms of being an internet addict: 29. Your phone bill comes to your doorstep in a box. /// Bram Moolenaar --
          Message 4 of 4 , Mar 7, 2013
          • 0 Attachment
            David Bürgin wrote:

            > I see. I was thinking about it the wrong way then.
            >
            > On Thursday, March 7, 2013 5:35:24 PM UTC+1, Ben Fritz wrote:
            > > > gUe suMMER
            > > > :norm! gUe<CR> suMMER
            > > > gU:norm! e<CR> suMMEr
            > >
            > > I'm not sure if this is documented (I couldn't find it mentioned
            > > explicitly) but if I recall correctly, any : command in operator-pending
            > > mode acts as an exclusive motion.
            >
            > Yes, I did see that in the code for the colon command at normal.c#5398:
            >
            > if (cap->oap->op_type != OP_NOP)
            > {
            > /* Using ":" as a movement is characterwise exclusive. */
            > cap->oap->motion_type = MCHAR;
            > cap->oap->inclusive = FALSE;
            > }
            >
            > I added a note in the documentation and removed a now invalid item from
            > the todo list.

            Thanks!

            --
            hundred-and-one symptoms of being an internet addict:
            29. Your phone bill comes to your doorstep in a box.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ an exciting new programming language -- http://www.Zimbu.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            --
            You received this message from the "vim_dev" 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_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+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.