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

{count}v command

Expand Messages
  • Marcin Szamotulski
    Dear Vim Dev, I recently found that v with count remembers the previous visual area. I found that it is not always true, which seems strange to me (is this a
    Message 1 of 8 , Oct 31, 2012
    • 0 Attachment
      Dear Vim Dev,

      I recently found that v with count remembers the previous visual area.
      I found that it is not always true, which seems strange to me (is this
      a feature or a bug?). For example if I do "v{motion}y", then "1v", as
      should, selects the same are in the current position. But if I do
      "v{motion}<esc>" or "v{motion}<c-c>" then "1v" doesn't remember the
      last visual area but the previous one. With <esc>/<c-c> I thing it
      would be nice if <esc> could remember the last area and <c-c> don't
      (this already happens with some features: for example <c-c> doesn't
      trigger InsertLeave autocommands when leaving the insert mode.)

      Best regards,
      Marcin Szamotulski

      --
      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
    • Ingo Karkat
      ... This has been discussed before: https://groups.google.com/d/topic/vim_dev/381bdn3wuuM/discussion ... Like you, some found this behavior unexpected, but we
      Message 2 of 8 , Oct 31, 2012
      • 0 Attachment
        On 31-Oct-2012 10:02:33 +0100, Marcin Szamotulski wrote:

        > Dear Vim Dev,
        >
        > I recently found that v with count remembers the previous visual area.
        > I found that it is not always true, which seems strange to me (is this
        > a feature or a bug?). For example if I do "v{motion}y", then "1v", as
        > should, selects the same are in the current position. But if I do
        > "v{motion}<esc>" or "v{motion}<c-c>" then "1v" doesn't remember the
        > last visual area but the previous one. With <esc>/<c-c> I thing it
        > would be nice if <esc> could remember the last area and <c-c> don't
        > (this already happens with some features: for example <c-c> doesn't
        > trigger InsertLeave autocommands when leaving the insert mode.)

        This has been discussed before:

        https://groups.google.com/d/topic/vim_dev/381bdn3wuuM/discussion

        From Bram:
        > > The idea of "1v" is that a Visual operation can be repeated at another
        > > location. Thus the area is only stored when performing an operation.

        Like you, some found this behavior unexpected, but we couldn't convince Bram to
        change this (mostly to avoid breaking stuff that potentially relies on this
        behavior), and no patches were put forward.

        -- regards, ingo

        --
        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
      • Marcin Szamotulski
        ... Good to know. Is there a VimL workaround, or a plugin for this? Best, Marcin -- You received this message from the vim_dev maillist. Do not top-post!
        Message 3 of 8 , Oct 31, 2012
        • 0 Attachment
          On 10:15 Wed 31 Oct , Ingo Karkat wrote:
          > On 31-Oct-2012 10:02:33 +0100, Marcin Szamotulski wrote:
          >
          > > Dear Vim Dev,
          > >
          > > I recently found that v with count remembers the previous visual area.
          > > I found that it is not always true, which seems strange to me (is this
          > > a feature or a bug?). For example if I do "v{motion}y", then "1v", as
          > > should, selects the same are in the current position. But if I do
          > > "v{motion}<esc>" or "v{motion}<c-c>" then "1v" doesn't remember the
          > > last visual area but the previous one. With <esc>/<c-c> I thing it
          > > would be nice if <esc> could remember the last area and <c-c> don't
          > > (this already happens with some features: for example <c-c> doesn't
          > > trigger InsertLeave autocommands when leaving the insert mode.)
          >
          > This has been discussed before:
          >
          > https://groups.google.com/d/topic/vim_dev/381bdn3wuuM/discussion
          >
          > >From Bram:
          > > > The idea of "1v" is that a Visual operation can be repeated at another
          > > > location. Thus the area is only stored when performing an operation.
          >
          > Like you, some found this behavior unexpected, but we couldn't convince Bram to
          > change this (mostly to avoid breaking stuff that potentially relies on this
          > behavior), and no patches were put forward.
          >
          > -- regards, ingo
          >
          > --
          > 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

          Good to know.

          Is there a VimL workaround, or a plugin for this?

          Best,
          Marcin

          --
          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
        • Ingo Karkat
          ... You d have to determine the dimensions from the
          Message 4 of 8 , Oct 31, 2012
          • 0 Attachment
            On 31-Oct-2012 10:24:48 +0100, Marcin Szamotulski wrote:

            > On 10:15 Wed 31 Oct , Ingo Karkat wrote:
            >> On 31-Oct-2012 10:02:33 +0100, Marcin Szamotulski wrote:
            >>
            >>> Dear Vim Dev,
            >>>
            >>> I recently found that v with count remembers the previous visual area.
            >>> I found that it is not always true, which seems strange to me (is this
            >>> a feature or a bug?). For example if I do "v{motion}y", then "1v", as
            >>> should, selects the same are in the current position. But if I do
            >>> "v{motion}<esc>" or "v{motion}<c-c>" then "1v" doesn't remember the
            >>> last visual area but the previous one. With <esc>/<c-c> I thing it
            >>> would be nice if <esc> could remember the last area and <c-c> don't
            >>> (this already happens with some features: for example <c-c> doesn't
            >>> trigger InsertLeave autocommands when leaving the insert mode.)
            >>
            >> This has been discussed before:
            >>
            >> https://groups.google.com/d/topic/vim_dev/381bdn3wuuM/discussion
            >>
            >> >From Bram:
            >>>> The idea of "1v" is that a Visual operation can be repeated at another
            >>>> location. Thus the area is only stored when performing an operation.
            >>
            >> Like you, some found this behavior unexpected, but we couldn't convince Bram to
            >> change this (mostly to avoid breaking stuff that potentially relies on this
            >> behavior), and no patches were put forward.
            >>
            >> -- regards, ingo
            >>
            >> --
            >> 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
            >
            > Good to know.
            >
            > Is there a VimL workaround, or a plugin for this?

            You'd have to determine the dimensions from the '< and '> marks, and create a
            new visual selection with the same dimensions.

            Or (simpler, but more hackish) just make a no-op modification to the selection,
            e.g. with gu followed by :undo, or maybe g?gvg?.

            -- regards, ingo

            --
            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
          • Marcin Szamotulski
            ... g?gvg? is really nice, I ll give it a try. I tested it over digraphs, and it works. Thanks, Marcin -- You received this message from the vim_dev
            Message 5 of 8 , Oct 31, 2012
            • 0 Attachment
              On 10:40 Wed 31 Oct , Ingo Karkat wrote:
              > On 31-Oct-2012 10:24:48 +0100, Marcin Szamotulski wrote:
              >
              > > On 10:15 Wed 31 Oct , Ingo Karkat wrote:
              > >> On 31-Oct-2012 10:02:33 +0100, Marcin Szamotulski wrote:
              > >>
              > >>> Dear Vim Dev,
              > >>>
              > >>> I recently found that v with count remembers the previous visual area.
              > >>> I found that it is not always true, which seems strange to me (is this
              > >>> a feature or a bug?). For example if I do "v{motion}y", then "1v", as
              > >>> should, selects the same are in the current position. But if I do
              > >>> "v{motion}<esc>" or "v{motion}<c-c>" then "1v" doesn't remember the
              > >>> last visual area but the previous one. With <esc>/<c-c> I thing it
              > >>> would be nice if <esc> could remember the last area and <c-c> don't
              > >>> (this already happens with some features: for example <c-c> doesn't
              > >>> trigger InsertLeave autocommands when leaving the insert mode.)
              > >>
              > >> This has been discussed before:
              > >>
              > >> https://groups.google.com/d/topic/vim_dev/381bdn3wuuM/discussion
              > >>
              > >> >From Bram:
              > >>>> The idea of "1v" is that a Visual operation can be repeated at another
              > >>>> location. Thus the area is only stored when performing an operation.
              > >>
              > >> Like you, some found this behavior unexpected, but we couldn't convince Bram to
              > >> change this (mostly to avoid breaking stuff that potentially relies on this
              > >> behavior), and no patches were put forward.
              > >>
              > >> -- regards, ingo
              > >>
              > >> --
              > >> 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
              > >
              > > Good to know.
              > >
              > > Is there a VimL workaround, or a plugin for this?
              >
              > You'd have to determine the dimensions from the '< and '> marks, and create a
              > new visual selection with the same dimensions.
              >
              > Or (simpler, but more hackish) just make a no-op modification to the selection,
              > e.g. with gu followed by :undo, or maybe g?gvg?.
              >
              > -- regards, ingo
              >
              > --
              > 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

              g?gvg? is really nice, I'll give it a try. I tested it over digraphs,
              and it works.

              Thanks,
              Marcin

              --
              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
            • ZyX
              ... You can also use ... . Unlike g? workaround it alters neither undo nor command history. -- You received this message from the vim_dev maillist. Do not
              Message 6 of 8 , Oct 31, 2012
              • 0 Attachment
                > g?gvg? is really nice, I'll give it a try. I tested it over digraphs,
                > and it works.

                You can also use

                :<C-u><Esc>
                . Unlike g? workaround it alters neither undo nor command history.

                --
                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
              • Ingo Karkat
                ... Great input, ZyX! For me, it even works without the , just : . Though this looks like a bug to me: I would understand that a no-op command like
                Message 7 of 8 , Oct 31, 2012
                • 0 Attachment
                  On 31-Oct-2012 20:43:19 +0100, ZyX wrote:

                  >> g?gvg? is really nice, I'll give it a try. I tested it over digraphs,
                  >> and it works.
                  >
                  > You can also use
                  >
                  > :<C-u><Esc>
                  > . Unlike g? workaround it alters neither undo nor command history.

                  Great input, ZyX! For me, it even works without the <C-u>, just :<Esc>. Though
                  this looks like a bug to me: I would understand that a no-op command like
                  :<C-u>echo<CR> would be treated as a modification, but an aborted command
                  definitely does not count as a modification; it also isn't added to the history.
                  I guess this special behavior is just a side effect of a simple implementation
                  that doesn't take command aborts into account.

                  The more I learn about it, the more I would prefer that {count}v _always_ uses
                  the previous selection (as proposed here again), modification yes or no. But I
                  guess we would need more vocal support to sway Bram, so please speak up! (Or
                  voice your concerns if you happen to know someone/thing that relies on the
                  current behavior.)

                  -- regards, ingo

                  --
                  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
                • ZyX
                  ... If it is typed (and that is how I tested it) then it adds to the history. Even if it is not typed then it may move the cursor (see :h cpo-x). You need to
                  Message 8 of 8 , Oct 31, 2012
                  • 0 Attachment
                    > Great input, ZyX! For me, it even works without the <C-u>, just :<Esc>. Though
                    > this looks like a bug to me: I would understand that a no-op command like
                    > :<C-u>echo<CR> would be treated as a modification, but an aborted command
                    > definitely does not count as a modification; it also isn't added to the history.
                    If it is typed (and that is how I tested it) then it adds to the history.
                    Even if it is not typed then it may move the cursor (see :h cpo-x). You need to use `<C-c>` to abort in `:<Esc>`, but it works for mappings only (I mean, not altering history in this case: typed `<C-c>` adds «'<,'>» to history as well).

                    > I guess this special behavior is just a side effect of a simple implementation
                    > that doesn't take command aborts into account.
                    >
                    > The more I learn about it, the more I would prefer that {count}v _always_ uses
                    > the previous selection (as proposed here again), modification yes or no. But I
                    > guess we would need more vocal support to sway Bram, so please speak up! (Or
                    > voice your concerns if you happen to know someone/thing that relies on the
                    > current behavior.)
                    I did not knew about {count}v until that thread you mentioned earlier. Neither I know about anything that relies on {count}v, including {count}v behavior currently being discussed.

                    It seems more consistent to me if gv and {count}v remembered the same selection though. But I have no voice here: no matter which behavior {count}v will show I am much unlikely to use it: to repeat selection operation it is *me* who must remember the last visual selection area or I am ending up with {count}v selecting random amount of characters (from my point of view, not from computer). I never remember it, only what *semantic elements* I selected, not what *amount of characters*. And my style of writing plugins dictates me to avoid altering vim state as much as possible, including altering current vim selection.

                    Hence the conclusion: {count}v using aborted selection seems better then {count}v using only selection that was operated upon, but I will use neither.

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