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

patch for block textobj search

Expand Messages
  • Daniel "paradigm" Thau
    I noticed a common pattern when using Vim: - I want to operate on a text object that is not under/around the cursor - The cursor is not over/in a text object
    Message 1 of 14 , Nov 19, 2013
      I noticed a common pattern when using Vim:
      - I want to operate on a text object that is not under/around the cursor
      - The cursor is not over/in a text object of this type.

      For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:

      x = 1;
      ...
      if (...) {
      ...
      }

      In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".

      However, in that situation the text-object commands don't do anything. We could have Vim do something useful in this context - jump to the desired text object. If the given text-object command is valid - if the cursor is already in a ()-block - then what Vim normally does should happen. However, if Vim is about to "return FAIL" could simply search the buffer for the object and, if it finds it, use that object instead.

      Moreover, block text-objects (parens, {}, [], <>) have two (or three!) ways to access them. This could be used to indicate direction. "vi(" will select the ()-block under/around the cursor or, if no such block exists in that area, searches forward for a ()-block. "vi)" will do the same except it will search in reverse. "vib" will just act as it always has. Similar actions will be used on {}, [], and <>.

      Attached is a patch (both in the context and unified formats) to implement this. It seems relatively simple/clean to me, but people looking over and testing would be benficial in case I failed to consider something.

      --
      --
      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
      ... No, in this situation the text object certainly CAN do something, because these text objects can be nested! Consider the [ai][{B] text object you mention.
      Message 2 of 14 , Nov 19, 2013
        On Tuesday, November 19, 2013 1:25:48 PM UTC-6, Daniel "paradigm" Thau wrote:
        > I noticed a common pattern when using Vim:
        > - I want to operate on a text object that is not under/around the cursor
        > - The cursor is not over/in a text object of this type.
        >
        > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
        >
        > x = 1;
        > ...
        > if (...) {
        > ...
        > }
        >
        > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
        >
        > However, in that situation the text-object commands don't do anything.

        No, in this situation the text object certainly CAN do something, because these text objects can be nested!

        Consider the [ai][{B] text object you mention. Chances are, you're inside a function when your cursor is on the "x=1" line. So pressing va{ should select the entire function body. It should not select the next block after 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.
      • Daniel "paradigm" Thau
        ... Perhaps I was unclear. *If* the text object can do something, then it does that thing. If there is some larger ()-object that isn t seen in my example,
        Message 3 of 14 , Nov 19, 2013
          On Tuesday, November 19, 2013 3:34:21 PM UTC-5, Ben Fritz wrote:
          > On Tuesday, November 19, 2013 1:25:48 PM UTC-6, Daniel "paradigm" Thau wrote:
          > > I noticed a common pattern when using Vim:
          > > - I want to operate on a text object that is not under/around the cursor
          > > - The cursor is not over/in a text object of this type.
          > >
          > > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
          > >
          > > x = 1;
          > > ...
          > > if (...) {
          > > ...
          > > }
          > >
          > > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
          > >
          > > However, in that situation the text-object commands don't do anything.
          >
          > No, in this situation the text object certainly CAN do something, because these text objects can be nested!
          >
          > Consider the [ai][{B] text object you mention. Chances are, you're inside a function when your cursor is on the "x=1" line. So pressing va{ should select the entire function body. It should not select the next block after the cursor.

          Perhaps I was unclear. *If* the text object can do something, then it does that thing. If there is some larger ()-object that isn't seen in my example, then yes, that would be selected. Only if the text object command fails - literally, it gets to the part of the code that does a "return FAIL" - does it search forward/backward for the object. Neither this patch nor my other one will alter normally valid Vim 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.
        • Christian Brabandt
          Hi Daniel! ... I think it should be ( to move to the previous object and ) to move to the next block. This would match the behaviour of [s ]s and [z and ]z and
          Message 4 of 14 , Nov 19, 2013
            Hi Daniel!

            On Di, 19 Nov 2013, Daniel paradigm Thau wrote:

            > I noticed a common pattern when using Vim:
            > - I want to operate on a text object that is not under/around the cursor
            > - The cursor is not over/in a text object of this type.
            >
            > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
            >
            > x = 1;
            > ...
            > if (...) {
            > ...
            > }
            >
            > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
            >
            > However, in that situation the text-object commands don't do anything. We could have Vim do something useful in this context - jump to the desired text object. If the given text-object command is valid - if the cursor is already in a ()-block - then what Vim normally does should happen. However, if Vim is about to "return FAIL" could simply search the buffer for the object and, if it finds it, use that object instead.
            >
            > Moreover, block text-objects (parens, {}, [], <>) have two (or three!) ways to access them. This could be used to indicate direction. "vi(" will select the ()-block under/around the cursor or, if no such block exists in that area, searches forward for a ()-block. "vi)" will do the same except it will search in reverse. "vib" will just act as it always has. Similar actions will be used on {}, [], and <>.
            >

            I think it should be ( to move to the previous object and ) to move to
            the next block. This would match the behaviour of [s ]s and [z and ]z
            and other similar motions.

            Other then that, this sounds like a useful addition (although some
            scripts might depend on the current behaviour).

            regards,
            Christian
            --
            "Sie brauchen den Mund nicht so weit aufmachen", sagte der Zahnarzt
            "Wollen Sie denn nicht bohren?"
            "Doch, schon, ... aber ich bleibe draußen."

            --
            --
            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.
          • Daniel "paradigm" Thau
            ... Hi Christian, Thanks for the input. That makes perfect sense to me. Adjusted patches are attached. -- -- You received this message from the vim_dev
            Message 5 of 14 , Nov 19, 2013
              On Tuesday, November 19, 2013 4:42:45 PM UTC-5, Christian Brabandt wrote:
              > Hi Daniel!
              >
              >
              >
              > On Di, 19 Nov 2013, Daniel paradigm Thau wrote:
              >
              >
              >
              > > I noticed a common pattern when using Vim:
              >
              > > - I want to operate on a text object that is not under/around the cursor
              >
              > > - The cursor is not over/in a text object of this type.
              >
              > >
              >
              > > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
              >
              > >
              >
              > > x = 1;
              >
              > > ...
              >
              > > if (...) {
              >
              > > ...
              >
              > > }
              >
              > >
              >
              > > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
              >
              > >
              >
              > > However, in that situation the text-object commands don't do anything. We could have Vim do something useful in this context - jump to the desired text object. If the given text-object command is valid - if the cursor is already in a ()-block - then what Vim normally does should happen. However, if Vim is about to "return FAIL" could simply search the buffer for the object and, if it finds it, use that object instead.
              >
              > >
              >
              > > Moreover, block text-objects (parens, {}, [], <>) have two (or three!) ways to access them. This could be used to indicate direction. "vi(" will select the ()-block under/around the cursor or, if no such block exists in that area, searches forward for a ()-block. "vi)" will do the same except it will search in reverse. "vib" will just act as it always has. Similar actions will be used on {}, [], and <>.
              >
              > >
              >
              >
              >
              > I think it should be ( to move to the previous object and ) to move to
              >
              > the next block. This would match the behaviour of [s ]s and [z and ]z
              >
              > and other similar motions.
              >
              >
              >
              > Other then that, this sounds like a useful addition (although some
              >
              > scripts might depend on the current behaviour).
              >
              >
              >
              > regards,
              >
              > Christian
              >
              > --
              >
              > "Sie brauchen den Mund nicht so weit aufmachen", sagte der Zahnarzt
              >
              > "Wollen Sie denn nicht bohren?"
              >
              > "Doch, schon, ... aber ich bleibe drau�en."

              Hi Christian,

              Thanks for the input. That makes perfect sense to me. Adjusted patches are attached.

              --
              --
              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.
            • Daniel "paradigm" Thau
              ... Attached is a newer version of the same patch with reworked code to be a bit cleaner. It includes Christian s suggestion for the search direction. -- --
              Message 6 of 14 , Nov 20, 2013
                On Tuesday, November 19, 2013 2:25:48 PM UTC-5, Daniel "paradigm" Thau wrote:
                > I noticed a common pattern when using Vim:
                > - I want to operate on a text object that is not under/around the cursor
                > - The cursor is not over/in a text object of this type.
                >
                > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
                >
                > x = 1;
                > ...
                > if (...) {
                > ...
                > }
                >
                > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
                >
                > However, in that situation the text-object commands don't do anything. We could have Vim do something useful in this context - jump to the desired text object. If the given text-object command is valid - if the cursor is already in a ()-block - then what Vim normally does should happen. However, if Vim is about to "return FAIL" could simply search the buffer for the object and, if it finds it, use that object instead.
                >
                > Moreover, block text-objects (parens, {}, [], <>) have two (or three!) ways to access them. This could be used to indicate direction. "vi(" will select the ()-block under/around the cursor or, if no such block exists in that area, searches forward for a ()-block. "vi)" will do the same except it will search in reverse. "vib" will just act as it always has. Similar actions will be used on {}, [], and <>.
                >
                > Attached is a patch (both in the context and unified formats) to implement this. It seems relatively simple/clean to me, but people looking over and testing would be benficial in case I failed to consider something.

                Attached is a newer version of the same patch with reworked code to be a bit cleaner. It includes Christian's suggestion for the search direction.

                --
                --
                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.
              • Daniel "paradigm" Thau
                ... The attachments didn t seem to stick; trying again. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the
                Message 7 of 14 , Nov 20, 2013
                  On Wednesday, November 20, 2013 7:16:59 PM UTC-5, Daniel "paradigm" Thau wrote:
                  > On Tuesday, November 19, 2013 2:25:48 PM UTC-5, Daniel "paradigm" Thau wrote:
                  > > I noticed a common pattern when using Vim:
                  > > - I want to operate on a text object that is not under/around the cursor
                  > > - The cursor is not over/in a text object of this type.
                  > >
                  > > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
                  > >
                  > > x = 1;
                  > > ...
                  > > if (...) {
                  > > ...
                  > > }
                  > >
                  > > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
                  > >
                  > > However, in that situation the text-object commands don't do anything. We could have Vim do something useful in this context - jump to the desired text object. If the given text-object command is valid - if the cursor is already in a ()-block - then what Vim normally does should happen. However, if Vim is about to "return FAIL" could simply search the buffer for the object and, if it finds it, use that object instead.
                  > >
                  > > Moreover, block text-objects (parens, {}, [], <>) have two (or three!) ways to access them. This could be used to indicate direction. "vi(" will select the ()-block under/around the cursor or, if no such block exists in that area, searches forward for a ()-block. "vi)" will do the same except it will search in reverse. "vib" will just act as it always has. Similar actions will be used on {}, [], and <>.
                  > >
                  > > Attached is a patch (both in the context and unified formats) to implement this. It seems relatively simple/clean to me, but people looking over and testing would be benficial in case I failed to consider something.
                  >
                  > Attached is a newer version of the same patch with reworked code to be a bit cleaner. It includes Christian's suggestion for the search direction.

                  The attachments didn't seem to stick; trying again.

                  --
                  --
                  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.
                • Daniel "paradigm" Thau
                  ... Aaand I did the wrong patches. My apologies, here goes try three. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your
                  Message 8 of 14 , Nov 20, 2013
                    On Wednesday, November 20, 2013 7:17:57 PM UTC-5, Daniel "paradigm" Thau wrote:
                    > On Wednesday, November 20, 2013 7:16:59 PM UTC-5, Daniel "paradigm" Thau wrote:
                    > > On Tuesday, November 19, 2013 2:25:48 PM UTC-5, Daniel "paradigm" Thau wrote:
                    > > > I noticed a common pattern when using Vim:
                    > > > - I want to operate on a text object that is not under/around the cursor
                    > > > - The cursor is not over/in a text object of this type.
                    > > >
                    > > > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
                    > > >
                    > > > x = 1;
                    > > > ...
                    > > > if (...) {
                    > > > ...
                    > > > }
                    > > >
                    > > > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
                    > > >
                    > > > However, in that situation the text-object commands don't do anything. We could have Vim do something useful in this context - jump to the desired text object. If the given text-object command is valid - if the cursor is already in a ()-block - then what Vim normally does should happen. However, if Vim is about to "return FAIL" could simply search the buffer for the object and, if it finds it, use that object instead.
                    > > >
                    > > > Moreover, block text-objects (parens, {}, [], <>) have two (or three!) ways to access them. This could be used to indicate direction. "vi(" will select the ()-block under/around the cursor or, if no such block exists in that area, searches forward for a ()-block. "vi)" will do the same except it will search in reverse. "vib" will just act as it always has. Similar actions will be used on {}, [], and <>.
                    > > >
                    > > > Attached is a patch (both in the context and unified formats) to implement this. It seems relatively simple/clean to me, but people looking over and testing would be benficial in case I failed to consider something.
                    > >
                    > > Attached is a newer version of the same patch with reworked code to be a bit cleaner. It includes Christian's suggestion for the search direction.
                    >
                    > The attachments didn't seem to stick; trying again.

                    Aaand I did the wrong patches. My apologies, here goes try three.

                    --
                    --
                    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
                    ... I suppose the behavior could be useful in some situations. It would be good to include tests. The more complicated the code gets, the more important it is
                    Message 9 of 14 , Nov 21, 2013
                      Daneil Thau wrote:

                      > On Wednesday, November 20, 2013 7:17:57 PM UTC-5, Daniel "paradigm" Thau wrote:
                      > > On Wednesday, November 20, 2013 7:16:59 PM UTC-5, Daniel "paradigm" Thau wrote:
                      > > > On Tuesday, November 19, 2013 2:25:48 PM UTC-5, Daniel "paradigm" Thau wrote:
                      > > > > I noticed a common pattern when using Vim:
                      > > > > - I want to operate on a text object that is not under/around the cursor
                      > > > > - The cursor is not over/in a text object of this type.
                      > > > >
                      > > > > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
                      > > > >
                      > > > > x = 1;
                      > > > > ...
                      > > > > if (...) {
                      > > > > ...
                      > > > > }
                      > > > >
                      > > > > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
                      > > > >
                      > > > > However, in that situation the text-object commands don't do anything. We could have Vim do something useful in this context - jump to the desired text object. If the given text-object command is valid - if the cursor is already in a ()-block - then what Vim normally does should happen. However, if Vim is about to "return FAIL" could simply search the buffer for the object and, if it finds it, use that object instead.
                      > > > >
                      > > > > Moreover, block text-objects (parens, {}, [], <>) have two (or three!) ways to access them. This could be used to indicate direction. "vi(" will select the ()-block under/around the cursor or, if no such block exists in that area, searches forward for a ()-block. "vi)" will do the same except it will search in reverse. "vib" will just act as it always has. Similar actions will be used on {}, [], and <>.
                      > > > >
                      > > > > Attached is a patch (both in the context and unified formats) to implement this. It seems relatively simple/clean to me, but people looking over and testing would be benficial in case I failed to consider something.
                      > > >
                      > > > Attached is a newer version of the same patch with reworked code to be a bit cleaner. It includes Christian's suggestion for the search direction.
                      > >
                      > > The attachments didn't seem to stick; trying again.
                      >
                      > Aaand I did the wrong patches. My apologies, here goes try three.

                      I suppose the behavior could be useful in some situations.

                      It would be good to include tests. The more complicated the code gets,
                      the more important it is to have tests that it works properly.

                      --
                      For large projects, Team Leaders use sophisticated project management software
                      to keep track of who's doing what. The software collects the lies and guesses
                      of the project team and organizes them in to instantly outdated charts that
                      are too boring to look at closely. This is called "planning".
                      (Scott Adams - The Dilbert principle)

                      /// 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.
                    • Daniel "paradigm" Thau
                      ... Roger. I ll be sure to add tests to both my patches. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below
                      Message 10 of 14 , Nov 21, 2013
                        On Thursday, November 21, 2013 7:25:02 AM UTC-5, Bram Moolenaar wrote:
                        > Daneil Thau wrote:
                        >
                        >
                        >
                        > > On Wednesday, November 20, 2013 7:17:57 PM UTC-5, Daniel "paradigm" Thau wrote:
                        >
                        > > > On Wednesday, November 20, 2013 7:16:59 PM UTC-5, Daniel "paradigm" Thau wrote:
                        >
                        > > > > On Tuesday, November 19, 2013 2:25:48 PM UTC-5, Daniel "paradigm" Thau wrote:
                        >
                        > > > > > I noticed a common pattern when using Vim:
                        >
                        > > > > > - I want to operate on a text object that is not under/around the cursor
                        >
                        > > > > > - The cursor is not over/in a text object of this type.
                        >
                        > > > > >
                        >
                        > > > > > For example, with the cursor on the "x" and a desire to operate on the conditional part of the if-statement:
                        >
                        > > > > >
                        >
                        > > > > > x = 1;
                        >
                        > > > > > ...
                        >
                        > > > > > if (...) {
                        >
                        > > > > > ...
                        >
                        > > > > > }
                        >
                        > > > > >
                        >
                        > > > > > In these situations I have been moving the cursor to the object then selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
                        >
                        > > > > >
                        >
                        > > > > > However, in that situation the text-object commands don't do anything. We could have Vim do something useful in this context - jump to the desired text object. If the given text-object command is valid - if the cursor is already in a ()-block - then what Vim normally does should happen. However, if Vim is about to "return FAIL" could simply search the buffer for the object and, if it finds it, use that object instead.
                        >
                        > > > > >
                        >
                        > > > > > Moreover, block text-objects (parens, {}, [], <>) have two (or three!) ways to access them. This could be used to indicate direction. "vi(" will select the ()-block under/around the cursor or, if no such block exists in that area, searches forward for a ()-block. "vi)" will do the same except it will search in reverse. "vib" will just act as it always has. Similar actions will be used on {}, [], and <>.
                        >
                        > > > > >
                        >
                        > > > > > Attached is a patch (both in the context and unified formats) to implement this. It seems relatively simple/clean to me, but people looking over and testing would be benficial in case I failed to consider something.
                        >
                        > > > >
                        >
                        > > > > Attached is a newer version of the same patch with reworked code to be a bit cleaner. It includes Christian's suggestion for the search direction.
                        >
                        > > >
                        >
                        > > > The attachments didn't seem to stick; trying again.
                        >
                        > >
                        >
                        > > Aaand I did the wrong patches. My apologies, here goes try three.
                        >
                        >
                        >
                        > I suppose the behavior could be useful in some situations.
                        >
                        >
                        >
                        > It would be good to include tests. The more complicated the code gets,
                        >
                        > the more important it is to have tests that it works properly.
                        >
                        >
                        >
                        > --
                        >
                        > For large projects, Team Leaders use sophisticated project management software
                        >
                        > to keep track of who's doing what. The software collects the lies and guesses
                        >
                        > of the project team and organizes them in to instantly outdated charts that
                        >
                        > are too boring to look at closely. This is called "planning".
                        >
                        > (Scott Adams - The Dilbert principle)
                        >
                        >
                        >
                        > /// 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 ///

                        Roger. I'll be sure to add tests to both my patches.

                        --
                        --
                        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.
                      • Daniel "paradigm" Thau
                        Apologies for the delay. Review for those who have forgotten and/or don t care to backread: With this patch, if the user attempts to use a block textobject
                        Message 11 of 14 , Jan 29 4:40 PM
                          Apologies for the delay.

                          Review for those who have forgotten and/or don't care to backread:

                          With this patch, if the user attempts to use a block textobject (parenthesis, square brackets, curley brackets, angle brackets) and the cursor is not already within the object, vim will search for the object in a given direction. For example, if the cursor is on one of the "l"'s below and the user enters "ci)OK<esc>"

                          lll(mmm)rrr

                          the following will result:

                          lll(OK)rrr

                          Note that this should not touch any already valid Vim input; only in the contexts where block text object commands do *not* already work does this do anything.

                          I've been using it quite happily for the last two months or so, but more eyes and testing would not be a bad idea.

                          Attached is the patch, in both unified and context format, including a test.

                          --
                          --
                          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.
                        • Daniel "paradigm" Thau
                          ... Forgot to include the alternations for the Makefile to include the new test; should be fixed in this attachment. -- -- You received this message from the
                          Message 12 of 14 , Jan 31 11:52 AM
                            On Wednesday, January 29, 2014 7:40:10 PM UTC-5, Daniel "paradigm" Thau wrote:
                            > Apologies for the delay.
                            >
                            > Review for those who have forgotten and/or don't care to backread:
                            >
                            > With this patch, if the user attempts to use a block textobject (parenthesis, square brackets, curley brackets, angle brackets) and the cursor is not already within the object, vim will search for the object in a given direction. For example, if the cursor is on one of the "l"'s below and the user enters "ci)OK<esc>"
                            >
                            > lll(mmm)rrr
                            >
                            > the following will result:
                            >
                            > lll(OK)rrr
                            >
                            > Note that this should not touch any already valid Vim input; only in the contexts where block text object commands do *not* already work does this do anything.
                            >
                            > I've been using it quite happily for the last two months or so, but more eyes and testing would not be a bad idea.
                            >
                            > Attached is the patch, in both unified and context format, including a test.

                            Forgot to include the alternations for the Makefile to include the new test; should be fixed in this attachment.

                            --
                            --
                            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.
                          • Tom McDonald
                            ... I m getting the feeling that this would cause pain in some scenarios. Consider JavaScript code like this: var Foo = augment(Object, function () {
                            Message 13 of 14 , Jun 17, 2014
                              On Friday, January 31, 2014 2:52:38 PM UTC-5, Daniel "paradigm" Thau wrote:
                              > On Wednesday, January 29, 2014 7:40:10 PM UTC-5, Daniel "paradigm" Thau wrote:
                              > > Apologies for the delay.
                              > >
                              > > Review for those who have forgotten and/or don't care to backread:
                              > >
                              > > With this patch, if the user attempts to use a block textobject (parenthesis, square brackets, curley brackets, angle brackets) and the cursor is not already within the object, vim will search for the object in a given direction. For example, if the cursor is on one of the "l"'s below and the user enters "ci)OK<esc>"
                              > >
                              > > lll(mmm)rrr
                              > >
                              > > the following will result:
                              > >
                              > > lll(OK)rrr
                              > >
                              > > Note that this should not touch any already valid Vim input; only in the contexts where block text object commands do *not* already work does this do anything.
                              > >
                              > > I've been using it quite happily for the last two months or so, but more eyes and testing would not be a bad idea.
                              > >
                              > > Attached is the patch, in both unified and context format, including a test.
                              >
                              > Forgot to include the alternations for the Makefile to include the new test; should be fixed in this attachment.

                              I'm getting the feeling that this would cause pain in some scenarios. Consider JavaScript code like this:

                              var Foo = augment(Object, function () {

                              this.method = function () {
                              // some method
                              };

                              this.otherMethod = function (a, b, c) {
                              // some other method
                              };

                              });

                              This example is short, but imagine a much longer one. If my cursor were somewhere near "otherMethod", I might expect that ci) would bring me to the function parameters that follow on the same line. However, I'm already inside a ()-block, and if I'm just focusing on the immediate context, it's quite easy to miss that.

                              I would be pretty disoriented if I ended up in Insert mode with nearly my entire buffer emptied when all I tried to do was change some function parameters to the right of my cursor. In the end, I'd have a hard time getting myself to trust these text objects.

                              The instances where Vim presently scans the line for the next text object are well-justified, and won't lead to huge surprises, because those text objects are only valid over a single line (e.g. quoted strings).

                              --
                              --
                              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/d/optout.
                            • Daniel "paradigm" Thau
                              ... I can see why you d expect that, but in my experience that s never come up. It may be I have a better sense of context than other users, although I
                              Message 14 of 14 , Jun 17, 2014
                                On Tuesday, June 17, 2014 1:17:02 PM UTC-4, Tom McDonald wrote:
                                > On Friday, January 31, 2014 2:52:38 PM UTC-5, Daniel "paradigm" Thau wrote:
                                > > On Wednesday, January 29, 2014 7:40:10 PM UTC-5, Daniel "paradigm" Thau wrote:
                                > > > Apologies for the delay.
                                > > >
                                > > > Review for those who have forgotten and/or don't care to backread:
                                > > >
                                > > > With this patch, if the user attempts to use a block textobject (parenthesis, square brackets, curley brackets, angle brackets) and the cursor is not already within the object, vim will search for the object in a given direction. For example, if the cursor is on one of the "l"'s below and the user enters "ci)OK<esc>"
                                > > >
                                > > > lll(mmm)rrr
                                > > >
                                > > > the following will result:
                                > > >
                                > > > lll(OK)rrr
                                > > >
                                > > > Note that this should not touch any already valid Vim input; only in the contexts where block text object commands do *not* already work does this do anything.
                                > > >
                                > > > I've been using it quite happily for the last two months or so, but more eyes and testing would not be a bad idea.
                                > > >
                                > > > Attached is the patch, in both unified and context format, including a test.
                                > >
                                > > Forgot to include the alternations for the Makefile to include the new test; should be fixed in this attachment.
                                >
                                > I'm getting the feeling that this would cause pain in some scenarios. Consider JavaScript code like this:
                                >
                                > var Foo = augment(Object, function () {
                                >
                                > this.method = function () {
                                > // some method
                                > };
                                >
                                > this.otherMethod = function (a, b, c) {
                                > // some other method
                                > };
                                >
                                > });
                                >
                                > This example is short, but imagine a much longer one. If my cursor were somewhere near "otherMethod", I might expect that ci) would bring me to the function parameters that follow on the same line. However, I'm already inside a ()-block, and if I'm just focusing on the immediate context, it's quite easy to miss that.
                                >
                                > I would be pretty disoriented if I ended up in Insert mode with nearly my entire buffer emptied when all I tried to do was change some function parameters to the right of my cursor. In the end, I'd have a hard time getting myself to trust these text objects.
                                >
                                > The instances where Vim presently scans the line for the next text object are well-justified, and won't lead to huge surprises, because those text objects are only valid over a single line (e.g. quoted strings).

                                I can see why you'd expect that, but in my experience that's never come up. It may be I have a better sense of context than other users, although I suspect most users would become accustomed to it very quickly. Even if they wouldn't - this situation is fairly situationally specific. In *some* instances some subsets of the additional functionality provided by this would be of limited, use. In a {}-heavy program, the functionality here for {} wouldn't be as useful. If you were lisp'ing, the () stuff would be significantly less useful, and the other stuff wouldn't come up as much either. However, in your example, () would still be both useful and do exactly what one would expect. And in plenty of other languages/situations the functionality mentioned here does exactly what is expected. I wouldn't discount everything that this allows because in some situations some of it isn't useful.

                                --
                                --
                                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/d/optout.
                              Your message has been successfully submitted and would be delivered to recipients shortly.