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

"." fails to repeat the last executed operator with ":normal v"

Expand Messages
  • Kana Natsuno
    I often define my own text objects. But I noticed that some of them are not correctly repeatable with the . command. I investigated the cause of the
    Message 1 of 19 , Nov 29, 2012
      I often define my own text objects. But I noticed that some of them are
      not correctly repeatable with the "." command. I investigated the cause
      of the problem, and found a strange behavior about repeating an operator
      which is executed with a ":" command as a motion.

      If an operator is executed with a ":" command and the ":" command
      doesn't invoke Visual mode via :normal, the whole operation can be
      repeated correctly with the "." command. In this case, the ":" command
      is stored into the redo buffer as is. For example:

      ------------------------------------------------------------------------

      onoremap foo :<C-u>call Select()<CR>

      function! Select()
      " Select a region without ":normal v".
      let p = getpos('.')
      let p[2] += 3
      call setpos('.', p)
      endfunction

      call setline('.', 'abc defg hijkl')
      normal! 0
      silent normal dfoo
      echomsg string(getline('.'))
      "==> ' defg hijkl'

      delfunction Select
      call setline('.', 'abc defg hijkl')
      normal! 0w
      let v:errmsg = ''
      silent! normal! .
      echomsg string(v:errmsg)
      "==> 'E117: Unknown function: Select'
      echomsg string(getline('.'))
      "==> 'abc defg hijkl'

      ------------------------------------------------------------------------

      But if an operator is executed with a ":" command and the ":" command
      invokes Visual mode via :normal, the whole operation cannot be
      repeated correctly with the "." command. In this case, the ":" command
      is not stored into the redo buffer. For example:

      ------------------------------------------------------------------------

      onoremap foo :<C-u>call Select()<CR>

      function! Select()
      " Select a region with ":normal v".
      normal! viw
      endfunction

      call setline('.', 'abc defg hijkl')
      normal! 0
      silent normal dfoo
      echomsg string(getline('.'))
      "==> ' defg hijkl'

      delfunction Select
      call setline('.', 'abc defg hijkl')
      normal! 0w
      let v:errmsg = ''
      silent! normal! .
      echomsg string(v:errmsg)
      "==> '', but it should be 'E117: Unknown function: Select'
      echomsg string(getline('.'))
      "==> 'abc g hijkl', but it should be 'abc defg hijkl'

      ------------------------------------------------------------------------

      In the last example, the "." command repeats the last operation without
      error, even if the Select function is no longer existing. So that the
      redo buffer doesn't contains the last given ":" command as is.

      The ":normal v" trick is necessary to define text objects like iw, ap
      and others, because such text objects have to adjust the starting
      position of a pending operator from Operator-pending mode.
      But ":normal v" triggers the problem as described above.
      Is this behavior intentional one, or unintended drawback?

      --
      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
    • Kana Natsuno
      ... Don t you have any idea about this problem? -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text
      Message 2 of 19 , Mar 15, 2013
        On Thursday, November 29, 2012 11:35:08 PM UTC+9, Kana Natsuno wrote:
        > I often define my own text objects. But I noticed that some of them are
        > not correctly repeatable with the "." command. I investigated the cause
        > of the problem, and found a strange behavior about repeating an operator
        > which is executed with a ":" command as a motion.
        >
        > If an operator is executed with a ":" command and the ":" command
        > doesn't invoke Visual mode via :normal, the whole operation can be
        > repeated correctly with the "." command. In this case, the ":" command
        > is stored into the redo buffer as is. For example:
        >
        > [...]

        Don't you have any idea about this problem?

        --
        --
        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
        Here are the contents of the redo buffer when . is pressed, for both cases (I obtained these with get_inserted()): 1. d:call Select() n 2. vd So, in the
        Message 3 of 19 , Mar 16, 2013
          Here are the contents of the redo buffer when "." is pressed, for both
          cases (I obtained these with get_inserted()):

          1. "d:call Select()\n"
          2. "vd"

          So, in the first case when we enter "dfoo", "foo" is mapped and put
          verbatim in the redo buffer.

          In the second case, "dfoo" is somehow translated to "vd". The effect is
          the same as for "1vd", meaning: make a Visual selection with the same
          size as the previous one, then delete it.

          This is strange. I don't understand how the second case works yet but I
          will try to find out more when I have time.

          glts

          --
          --
          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
          ... The repeat.vim plugin was created to solve this problem but it doesn t work for omaps neither. I don t know if you saw it but there is some discussion
          Message 4 of 19 , Mar 17, 2013
            On Saturday, March 16, 2013 6:37:18 AM UTC+1, Kana Natsuno wrote:
            > Don't you have any idea about this problem?

            On Saturday, March 16, 2013 12:06:50 PM UTC+1, glts wrote:
            > Here are the contents of the redo buffer when ...

            The "repeat.vim" plugin was created to solve this problem but it doesn't
            work for omaps neither. I don't know if you saw it but there is some
            discussion here:

            https://github.com/tpope/vim-repeat/issues/8

            In my opinion, the redo buffer should be the same in both of your
            examples, namely "d:call Select()\n". But since there is only one redo
            buffer and you can call functions/:normal recursively, there's always
            the chance of it being overwritten.

            Folks, would it make sense to add another "top-level" redo buffer? This
            would be left untouched by nested :normal 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.
          • Kana Natsuno
            ... I already saw the discussion, because several people asked me about repeatability of custom text objects implemented with vim-textobj-user and most of them
            Message 5 of 19 , Mar 17, 2013
              On Sun, Mar 17, 2013 at 8:03 PM, glts wrote:
              > The "repeat.vim" plugin was created to solve this problem but it doesn't
              > work for omaps neither. I don't know if you saw it but there is some
              > discussion here:
              >
              > https://github.com/tpope/vim-repeat/issues/8

              I already saw the discussion, because several people asked me about
              repeatability of custom text objects implemented with vim-textobj-user
              and most of them also told me the link.

              But I don't believe that repeat.vim is a right solution for the problem.
              repeat.vim is to enable repeatability for custom operators which take
              extra arguments such as a {target} for ys{motion}{target} provided by
              surround.vim. Repeatability of custom motions and custom text objects
              should be covered by another layer. Especially, the "solution" posted
              in the discussion

              https://github.com/tpope/vim-repeat/issues/8#issuecomment-13951082

              does not work with custom operators using repeat.vim.


              > In my opinion, the redo buffer should be the same in both of your
              > examples, namely "d:call Select()\n". But since there is only one redo
              > buffer and you can call functions/:normal recursively, there's always
              > the chance of it being overwritten.
              >
              > Folks, would it make sense to add another "top-level" redo buffer? This
              > would be left untouched by nested :normal commands.

              Thank you for the summary. It seems to be reasonable for me, but there
              might be drawbacks about compatibility or difficulty for further
              maintenance. I'd like to hear others' opinions.

              --
              --
              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
              ... At this point I believe this is a bug. Consider the following commands, typed in normal mode: (1) d:call setpos( . ,[0,2,5,0]) (2) d:normal! e (3)
              Message 6 of 19 , Mar 19, 2013
                On Thursday, November 29, 2012 3:35:08 PM UTC+1, Kana Natsuno wrote:
                > I often define my own text objects. But I noticed that some of them are
                > not correctly repeatable with the "." command. I investigated the cause
                > of the problem, and found a strange behavior about repeating an operator
                > which is executed with a ":" command as a motion.
                > ...

                At this point I believe this is a bug. Consider the following commands,
                typed in normal mode:

                (1) d:call setpos(".",[0,2,5,0])
                (2) d:normal! e
                (3) dv:normal! viw
                (4) d:normal! viw

                Commands (1) to (3) work exactly as expected: "delete to line 2 column
                5; to the end of the word; the inner word". And they are repeatable with
                the dot command, because they are put in the redo buffer exactly as
                typed.

                Command (4) works as expected, but it isn't repeatable because the
                command isn't correctly put in the redo buffer.

                This is unfortunate. In Operator-pending mode, selecting something in
                Visual mode is special: Like Kana said, it is the only way to define
                complex text objects (see :h omap-info). So this is an issue that needs
                fixing.

                --
                --
                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.
              • Sung Pae
                ... While I do hope Vim will gain native support for repeating custom commands with `.`, I would like to point out that the posted solution, while hackish,
                Message 7 of 19 , Mar 19, 2013
                  On Sun, Mar 17, 2013 at 05:08:29AM -0700, Kana Natsuno wrote:

                  > Especially, the "solution" posted in the discussion
                  >
                  > https://github.com/tpope/vim-repeat/issues/8#issuecomment-13951082
                  >
                  > does not work with custom operators using repeat.vim.

                  While I do hope Vim will gain native support for repeating custom
                  commands with `.`, I would like to point out that the posted solution,
                  while hackish, indeed does work with custom operators, custom motions,
                  and even in combination.

                  I am close to releasing a plugin with 18 custom text objects and cursor
                  motions for S-Expressions, and I have a satisfactory¹ implementation of
                  repeatable operator-pending commands here:

                  https://github.com/guns/vim-sexp/blob/90cc836e9c83d4b96c6c5e971febc33a5d73f7e7/plugin/sexp.vim#L103..L132

                  The motion mappings created by the above function work with both native
                  operators and with the custom operators provided by two other plugins by
                  Tim Pope: vim-surround and vim-commentary. I don't know offhand if Tim
                  had to put in any extra work to make this possible, but I don't believe
                  so.

                  Sung Pae

                  ¹ Not perfect. The `c` command is special cased for now and the final
                  position of the cursor is sometimes different than with native
                  operations, but I think both issues could be resolved with some
                  ingenuity.

                  --
                  --
                  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.
                • Sung Pae
                  ... Apologies for replying to myself here, but I wish to emphasize that I am in _complete_ agreement with Kana Natsuno about his proposal. This should
                  Message 8 of 19 , Mar 19, 2013
                    On Tue, Mar 19, 2013 at 05:21:42PM -0500, Sung Pae wrote:
                    > On Sun, Mar 17, 2013 at 05:08:29AM -0700, Kana Natsuno wrote:
                    >
                    > > Especially, the "solution" posted in the discussion
                    > >
                    > > https://github.com/tpope/vim-repeat/issues/8#issuecomment-13951082
                    > >
                    > > does not work with custom operators using repeat.vim.
                    >
                    > While I do hope Vim will gain native support for repeating custom
                    > commands with `.`

                    Apologies for replying to myself here, but I wish to emphasize that I
                    am in _complete_ agreement with Kana Natsuno about his proposal. This
                    should optimally "just work" without any of the hackery I've posted.

                    Operators + cursor motions are one of the pillars of the Vim editing
                    philosophy and fixing this issue would definitely encourage people to
                    create their own innovative FileType-specific motions.

                    I would be happy to supply a patch if it is acknowledged as a bug, and
                    if Kana is not already in the midst of a solution.

                    Sung Pae

                    --
                    --
                    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 don t know if you saw my other post (Google groups separated it for some reason) but this has to be a bug. Compare: dv:norm! viw d:norm! viw The first
                    Message 9 of 19 , Mar 19, 2013
                      On Tuesday, March 19, 2013 11:52:35 PM UTC+1, Sung Pae wrote:
                      > Apologies for replying to myself here, but I wish to emphasize that I
                      > am in _complete_ agreement with Kana Natsuno about his proposal. This
                      > should optimally "just work" without any of the hackery I've posted.
                      >
                      > Operators + cursor motions are one of the pillars of the Vim editing
                      > philosophy and fixing this issue would definitely encourage people to
                      > create their own innovative FileType-specific motions.
                      >
                      > I would be happy to supply a patch if it is acknowledged as a bug, and
                      > if Kana is not already in the midst of a solution.

                      I don't know if you saw my other post (Google groups separated it for
                      some reason) but this has to be a bug. Compare:

                      dv:norm! viw
                      d:norm! viw

                      The first one is put into the redo buffer as is, the second one isn't
                      (the redo buffer contains "vd" in the second case). The only difference
                      is the motion force ("v") after the operator.

                      Looking at the source, I get the impression that this is simply an issue
                      of an improperly defined condition. I have a working two-line patch
                      which fixes this but I'd rather give it a little more time.

                      --
                      --
                      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.
                    • Kana Natsuno
                      ... No. The solution does not work in every situation, especially for a combination of a custom operator and a custom text object that use repeat.vim. ...
                      Message 10 of 19 , Mar 19, 2013
                        On Wed, Mar 20, 2013 at 7:21 AM, Sung Pae wrote:
                        > On Sun, Mar 17, 2013 at 05:08:29AM -0700, Kana Natsuno wrote:
                        >
                        >> Especially, the "solution" posted in the discussion
                        >>
                        >> https://github.com/tpope/vim-repeat/issues/8#issuecomment-13951082
                        >>
                        >> does not work with custom operators using repeat.vim.
                        >
                        > While I do hope Vim will gain native support for repeating custom
                        > commands with `.`, I would like to point out that the posted solution,
                        > while hackish, indeed does work with custom operators, custom motions,
                        > and even in combination.

                        No. The "solution" does not work in every situation, especially for
                        a combination of a custom operator and a custom text object that use
                        repeat.vim.


                        > I am close to releasing a plugin with 18 custom text objects and cursor
                        > motions for S-Expressions, and I have a satisfactory¹ implementation of
                        > repeatable operator-pending commands here:
                        >
                        > https://github.com/guns/vim-sexp/blob/90cc836e9c83d4b96c6c5e971febc33a5d73f7e7/plugin/sexp.vim#L103..L132
                        >
                        > The motion mappings created by the above function work with both native
                        > operators and with the custom operators provided by two other plugins by
                        > Tim Pope: vim-surround and vim-commentary.

                        Really? Suppose that we invoke a new Vim process with the following
                        environment:

                        ------------------------------------------------------------

                        $ git clone git://github.com/tpope/vim-repeat.git
                        $ cd vim-repeat
                        $ git checkout a81bef76031ca1c71766b516417480caeb01c932
                        $ cd ..
                        $ git clone git://github.com/guns/vim-sexp.git
                        $ cd vim-surround
                        $ git checkout 90cc836e9c83d4b96c6c5e971febc33a5d73f7e7
                        $ cd ..
                        $ git clone git://github.com/tpope/vim-surround.git
                        $ cd vim-surround
                        $ git checkout 02199ea0080d744ec76b79d74ce56d51d25cf7ae
                        $ cd ..
                        $ vim -u NONE -i NONE -N -c "
                        syntax enable |
                        set runtimepath+=$PWD/vim-repeat,$PWD/vim-sexp,$PWD/vim-surround |
                        runtime! plugin/sexp.vim plugin/surround.vim
                        "

                        ------------------------------------------------------------

                        Then `:setfiletype scheme` and paste the following snippet:

                        (let ((a b) (c d))
                        code)
                        (let ((e f)) more-code)

                        Suppose that we do

                        (1) `1ggf(` (move the cursor the second "(" in the first line)
                        (2) `ysabr` (surround the "(...)" block with "[" and "]"),
                        (3) `3ggf(` (move the cursor the second "(" in the third line)
                        (4) `.` (repeat (2), the last edit command)

                        We'll get the following result:

                        (let [((a b) (c d))]
                        code)
                        (let [((e f))] more-code)

                        If we do the following steps on the same snippet:

                        (1) `1ggf(`
                        (2) `ysafr` (surround the current form with "[" and "]"),
                        (3) `3ggf(`
                        (4) `.`

                        We'll get the following result:

                        (let [((a b) (c d))]
                        code)
                        (let [((e f)) more-]code)

                        That's why I don't believe that the "solution" is not a right way to
                        solve this problem. It does not provide repeatability for every
                        combination.

                        --
                        --
                        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.
                      • Sung Pae
                        ... Yes, this combination does fail due to the implementation of the `ys` operator. This can be ameliorated, but it would not be pretty. Other combinations do
                        Message 11 of 19 , Mar 19, 2013
                          On Tue, Mar 19, 2013 at 04:39:11PM -0700, Kana Natsuno wrote:

                          > On Wed, Mar 20, 2013 at 7:21 AM, Sung Pae wrote:
                          >
                          > > The motion mappings created by the above function work with both
                          > > native operators and with the custom operators provided by two other
                          > > plugins by Tim Pope: vim-surround and vim-commentary.
                          >
                          > Really? Suppose that we invoke a new Vim process with the following
                          > environment:
                          >
                          > ------------------------------------------------------------

                          Yes, this combination does fail due to the implementation of the `ys`
                          operator. This can be ameliorated, but it would not be pretty.

                          Other combinations do not fail (like the `gc` vim-commentary operator
                          with the `af` text object), and the native operators with custom text
                          objects work well.

                          Again, this is a hack against the constraints of the bug you have
                          pointed out, which I am very much in favor of seeing fixed. Do you have
                          a patch to supply to the list, or should I look into it?

                          Sung Pae

                          --
                          --
                          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.
                        • Yukihiro Nakadaira
                          Perhaps this works? onoremap foo : call Select() function! Select() execute normal! viw endfunction -- Yukihiro Nakadaira -
                          Message 12 of 19 , Mar 20, 2013
                            Perhaps this works?

                            onoremap foo :<C-u>call Select()<CR>
                            function! Select()
                              execute "normal! viw\<Esc>"
                            endfunction

                            --
                            Yukihiro Nakadaira - yukihiro.nakadaira@...

                            --
                            --
                            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.
                             
                             
                          • Yukihiro Nakadaira
                            ... Oops, this doesn t work. Sorry for noise. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you
                            Message 13 of 19 , Mar 20, 2013
                              On Wednesday, March 20, 2013 10:49:19 PM UTC+9, Yukihiro Nakadaira wrote:
                              > Perhaps this works?
                              >
                              > onoremap foo :<C-u>call Select()<CR>
                              > function! Select()
                              >   execute "normal! viw\<Esc>"
                              > endfunction

                              Oops, this doesn't work. Sorry for noise.

                              --
                              --
                              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
                              Hi ... I spent some time looking into this. Attached is a first *proposal* for a patch for the current Vim version 7.3.875, which -- I believe -- fixes this.
                              Message 14 of 19 , Mar 23, 2013
                                Hi

                                On Wednesday, March 20, 2013 1:07:53 AM UTC+1, Sung Pae wrote:
                                > On Tue, Mar 19, 2013 at 04:39:11PM -0700, Kana Natsuno wrote:
                                >
                                >
                                >
                                > > On Wed, Mar 20, 2013 at 7:21 AM, Sung Pae wrote:
                                >
                                > >
                                >
                                > > > The motion mappings created by the above function work with both
                                >
                                > > > native operators and with the custom operators provided by two other
                                >
                                > > > plugins by Tim Pope: vim-surround and vim-commentary.
                                >
                                > >
                                >
                                > > Really? Suppose that we invoke a new Vim process with the following
                                >
                                > > environment:
                                >
                                > >
                                >
                                > > ------------------------------------------------------------
                                >
                                >
                                >
                                > Yes, this combination does fail due to the implementation of the `ys`
                                >
                                > operator. This can be ameliorated, but it would not be pretty.
                                >
                                >
                                >
                                > Other combinations do not fail (like the `gc` vim-commentary operator
                                >
                                > with the `af` text object), and the native operators with custom text
                                >
                                > objects work well.
                                >
                                >
                                >
                                > Again, this is a hack against the constraints of the bug you have
                                >
                                > pointed out, which I am very much in favor of seeing fixed. Do you have
                                >
                                > a patch to supply to the list, or should I look into it?
                                >
                                >
                                >
                                > Sung Pae

                                I spent some time looking into this. Attached is a first *proposal* for
                                a patch for the current Vim version 7.3.875, which -- I believe -- fixes
                                this.

                                However, the code surrounding Visual mode and operators is rather ...
                                tricky to say the least, so I urge you to look it over carefully, and
                                comment on whether you think it is correct or how it could be improved.

                                There has not been any response on the status of this issue. Operators
                                and text objects are two of the major advantages Vim has over other
                                editors. So I believe it is essential to let users leverage the full
                                power of their own custom operators and text objects by making them
                                repeatable with the dot command.

                                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.
                              • Sung Pae
                                ... I can confirm it works for simple repeats of custom motions with `d` and `c` operators, as well the custom `ys` operator that Kana showed was problematic.
                                Message 15 of 19 , Mar 23, 2013
                                  On Sat, Mar 23, 2013 at 09:56:58AM -0700, glts wrote:

                                  > I spent some time looking into this. Attached is a first *proposal*
                                  > for a patch for the current Vim version 7.3.875, which -- I believe --
                                  > fixes this.

                                  I can confirm it works for simple repeats of custom motions with `d` and
                                  `c` operators, as well the custom `ys` operator that Kana showed was
                                  problematic.

                                  > However, the code surrounding Visual mode and operators is rather ...
                                  > tricky to say the least, so I urge you to look it over carefully,
                                  > and comment on whether you think it is correct or how it could be
                                  > improved.

                                  I see two issues on first glance:

                                  * Counts are not repeated; d2x (x being a custom motion) repeats as
                                  dx only
                                  * Making a visual selection with a custom operator clobbers the redo

                                  It's promising that your small patch enables so much of the desired
                                  functionality. Please continue!

                                  > There has not been any response on the status of this issue. Operators
                                  > and text objects are two of the major advantages Vim has over other
                                  > editors. So I believe it is essential to let users leverage the full
                                  > power of their own custom operators and text objects by making them
                                  > repeatable with the dot command.

                                  Perhaps we will be able to convince Bram if the solution is clean and
                                  unobtrusive.

                                  Sung Pae

                                  --
                                  --
                                  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
                                  Sung Pae, thank you for your feedback. ... Yes, but this is due to another bug. My patch does not affect this. ... If you try the normal mode mapping, e.g.
                                  Message 16 of 19 , Mar 24, 2013
                                    Sung Pae, thank you for your feedback.

                                    On Sun, Mar 24, 2013 at 12:40 AM, Sung Pae <self@...> wrote:
                                    > I see two issues on first glance:
                                    >
                                    > * Counts are not repeated; d2x (x being a custom motion) repeats as
                                    > dx only

                                    Yes, but this is due to another bug. My patch does not affect this.

                                    The v:count variables are treated differently in omaps. Compare:

                                    :nnoremap <silent> x :<C-U>exe "norm! d".v:count1."e"<CR>
                                    :onoremap <silent> x :<C-U>exe "norm! ".v:count1."e"<CR>

                                    If you try the normal mode mapping, e.g. "2x", then the dot command will
                                    have the same effect as "2x". You can also override the count by giving
                                    a count to the dot command, e.g. "3.". This is the expected behaviour.

                                    The omap on the other hand doesn't work like that. Try "d2x" and then
                                    repeat with the dot command: The original count is not used. You have to
                                    use "2." to get the same as with "d2x".

                                    This is a different issue, and I'd rather put it off for the moment.

                                    > * Making a visual selection with a custom operator clobbers the redo

                                    Can you give an example? I don't see the problem.

                                    --
                                    --
                                    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.
                                  • Sung Pae
                                    ... Ah yes, you re totally correct. I remember now that I had to work around that myself by saving v:count to a buffer-local variable on omap invocation, then
                                    Message 17 of 19 , Mar 24, 2013
                                      On Sun, Mar 24, 2013 at 06:43:47PM +0100, glts wrote:

                                      > On Sun, Mar 24, 2013 at 12:40 AM, Sung Pae <self@...> wrote:
                                      > > I see two issues on first glance:
                                      > >
                                      > > * Counts are not repeated; d2x (x being a custom motion) repeats as
                                      > > dx only
                                      >
                                      > Yes, but this is due to another bug. My patch does not affect this.
                                      >
                                      > The v:count variables are treated differently in omaps. Compare:

                                      Ah yes, you're totally correct. I remember now that I had to work
                                      around that myself by saving v:count to a buffer-local variable on omap
                                      invocation, then string-replace the v:count variable in the omap rhs
                                      with the buffer-local "b:_count", so that the cached value would be used
                                      on repeat. It was very nasty, but it worked.

                                      > This is a different issue, and I'd rather put it off for the moment.

                                      Yes, I imagine a new count variable needs to be created to handle omaps.

                                      > > * Making a visual selection with a custom operator clobbers the redo
                                      >
                                      > Can you give an example? I don't see the problem.

                                      I apologize, that was a bit vague.

                                      Let's create a simple (and incomplete) custom motion:

                                      function! SelectInCaps()
                                      let [bl, bc] = searchpos('\u', 'cbW')
                                      let [el, ec] = searchpos('.\u\ze', 'W')
                                      call setpos("'<", [0, bl, bc, 0])
                                      call setpos("'>", [0, el, ec, 0])
                                      normal! gv
                                      endfunction

                                      Then map it to both visual and operator-pending modes:

                                      vmap ic :<C-U>call SelectInCaps()<CR>
                                      omap ic :<C-U>call SelectInCaps()<CR>

                                      Repeating the command dic with the . command works now with your patch:

                                      Foo|BarBazQuux
                                      Foo|BazQuux " dic
                                      Foo|Quuz " .

                                      However, if we invoke vic after running dic, the . command no longer has
                                      any affect:

                                      Foo|BarBazQuux
                                      Foo|BazQuux " dic
                                      Foo|BazQuux " vic<Esc>
                                      Foo|BazQuux " .

                                      This is not true of the builtin motions like `aw`; visual commands do
                                      not clobber the repeat buffer (or however it may work).

                                      Thank you for your work on this!

                                      Sung Pae

                                      --
                                      --
                                      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
                                      ... Yes, sorry, and thanks for reporting. Operator and Visual mode handling isn t easy and I m learning it the hard way ... Anyway, after another session in
                                      Message 18 of 19 , Mar 25, 2013
                                        On Mon, Mar 25, 2013 at 2:08 AM, Sung Pae <self@...> wrote:
                                        > Let's create a simple (and incomplete) custom motion:
                                        >
                                        > function! SelectInCaps()
                                        > let [bl, bc] = searchpos('\u', 'cbW')
                                        > let [el, ec] = searchpos('.\u\ze', 'W')
                                        > call setpos("'<", [0, bl, bc, 0])
                                        > call setpos("'>", [0, el, ec, 0])
                                        > normal! gv
                                        > endfunction
                                        >
                                        > Then map it to both visual and operator-pending modes:
                                        >
                                        > vmap ic :<C-U>call SelectInCaps()<CR>
                                        > omap ic :<C-U>call SelectInCaps()<CR>
                                        >
                                        > Repeating the command dic with the . command works now with your patch:
                                        >
                                        > Foo|BarBazQuux
                                        > Foo|BazQuux " dic
                                        > Foo|Quuz " .
                                        >
                                        > However, if we invoke vic after running dic, the . command no longer has
                                        > any affect:
                                        >
                                        > Foo|BarBazQuux
                                        > Foo|BazQuux " dic
                                        > Foo|BazQuux " vic<Esc>
                                        > Foo|BazQuux " .

                                        Yes, sorry, and thanks for reporting. Operator and Visual mode handling
                                        isn't easy and I'm learning it the hard way ...

                                        Anyway, after another session in the debugger I came up with the slight
                                        amendment in the attachment. If you would like to try it, be my guest. I
                                        hope I can find the time to write a few tests.

                                        David

                                        --
                                        --
                                        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.
                                      • Sung Pae
                                        ... Yes, this definitely solves the problem with visual selections clearing the repeat. I tried poking around a bit more, and I couldn t find any obvious
                                        Message 19 of 19 , Mar 25, 2013
                                          On Mon, Mar 25, 2013 at 10:14:48PM +0100, glts wrote:

                                          > On Mon, Mar 25, 2013 at 2:08 AM, Sung Pae <self@...> wrote:
                                          >
                                          > > Let's create a simple (and incomplete) custom motion: …
                                          >
                                          > Anyway, after another session in the debugger I came up with the
                                          > slight amendment in the attachment. If you would like to try it, be my
                                          > guest. I hope I can find the time to write a few tests.

                                          Yes, this definitely solves the problem with visual selections clearing
                                          the repeat. I tried poking around a bit more, and I couldn't find any
                                          obvious problems, which is exciting.

                                          All that appears to be left to achieve parity with builtin cursor
                                          motions is the issue with v:count. I will report any problems should I
                                          find them.

                                          Thank you for looking into this.

                                          Sung Pae

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