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

gp vs p

Expand Messages
  • Axel Bender
    I m wondering if the behavior of normal mode p is correct in respect to the cursor position? The docs state for gp : Just like p , but leave the cursor
    Message 1 of 7 , Jan 4, 2013
    • 0 Attachment
      I'm wondering if the behavior of normal mode "p" is correct in respect to the cursor position?

      The docs state for "gp":

      "Just like "p", but leave the cursor just after the new text."

      which suggests/implies that after "p" the cursor should stay in its current position (which - unfortunately - is not the case).

      --
      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
    • Christian Brabandt
      Hi Axel! ... Well, the cursor positioning seems rather complicated for p and P, see the description of the standard:
      Message 2 of 7 , Jan 4, 2013
      • 0 Attachment
        Hi Axel!

        On Fr, 04 Jan 2013, Axel Bender wrote:

        > I'm wondering if the behavior of normal mode "p" is correct in respect to the cursor position?
        >
        > The docs state for "gp":
        >
        > "Just like "p", but leave the cursor just after the new text."
        >
        > which suggests/implies that after "p" the cursor should stay in its current position (which - unfortunately - is not the case).

        Well, the cursor positioning seems rather complicated for p and P, see
        the description of the standard:
        http://pubs.opengroup.org/onlinepubs/9699919799/
        (and search for Put from Buffer Following and Put from Buffer Before).

        However, when reading this section:

        ,----[ Put from Buffer Following ]-
        | Synopsis:
        | [buffer] p
        |
        | […]
        | Current column:
        |
        | If the buffer text is in character mode:
        |
        | If the text in the buffer is from more than a single line, then set to
        | the last column on which any portion of the first character from the
        | buffer is displayed.
        |
        | Otherwise, if the buffer is the unnamed buffer, set to the last column
        | on which any portion of the last character from the buffer is displayed.
        |
        | Otherwise, set to the first column on which any portion of the first
        | character from the buffer is displayed.
        `----

        Reading the last sentence, it seems to me, that Vim does not behave like
        this, in fact, 'p' for character mode always seems to move to the last
        inserted character. This sounds like a bug to me? (nvi behaves as
        documented). Should this be fixed (and possibly added yet-another flag
        to the 'cpo' setting)?

        Mit freundlichen Grüßen
        Christian
        --

        --
        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
      • Axel Bender
        Hi Christian, thanks for the answer. It goes along with my perception. I consider this a bug which needs a fix. Also, at times it would come very handy to have
        Message 3 of 7 , Jan 6, 2013
        • 0 Attachment
          Hi Christian,

          thanks for the answer. It goes along with my perception. I consider this a bug which needs a fix. Also, at times it would come very handy to have p's functionality being different from gp's.


          --
          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
        • Tony Mechelynck
          ... They are different. For characterwise put at least, p leaves the cursor on the last character of the inserted string while gp puts it immediately after it.
          Message 4 of 7 , Jan 6, 2013
          • 0 Attachment
            On 06/01/13 13:08, Axel Bender wrote:
            > Hi Christian,
            >
            > thanks for the answer. It goes along with my perception. I consider this a bug which needs a fix. Also, at times it would come very handy to have p's functionality being different from gp's.
            >
            >
            They are different. For characterwise put at least, p leaves the cursor
            on the last character of the inserted string while gp puts it
            immediately after it. And Bram is known to be extremely reluctant to
            accept any behaviour change which might break something in an existing
            script or mapping (even one not distributed with Vim).

            Best regards,
            Tony.
            --
            In Tennessee, it is illegal to shoot any game other than whales from a
            moving automobile.

            --
            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
          • Christian Brabandt
            Hi Axel! ... What exactly do you consider a bug? Using p is a pretty basic action and changing the cursor position will be a backwards incompatible change and
            Message 5 of 7 , Jan 6, 2013
            • 0 Attachment
              Hi Axel!

              On So, 06 Jan 2013, Axel Bender wrote:

              > Hi Christian,
              >
              > thanks for the answer. It goes along with my perception. I consider this a bug which needs a fix. Also, at times it would come very handy to have p's functionality being different from gp's.

              What exactly do you consider a bug? Using p is a pretty basic action and
              changing the cursor position will be a backwards incompatible change and
              will probably break many scripts, macros and maps, thus it is not very
              likely, that this behaviour is going to be "fixed", especially since
              nobody has complained until now.

              The best I can think of, is using something like the attached patch,
              which only changes the cursor position for characterwise put of single
              lines according to the POSIX standard (as quoted before, see also
              http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#tag_20_152_13_69).
              This introduces the new cpo-flag '[' (we are running out of arguments
              for the cpo setting so I used the first free char, that I found) and
              only works, if set cpo+=[ has been used.

              Mit freundlichen Grüßen
              Christian
              --
              Jetzt wächst zusammen, was zusammen gehört.
              -- Willy Brandt

              --
              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
            • Alexey
              ... Hmm nobody has complained ? Interesting. Maybe i would have complained, but i ve decided instead to remap *all* keys (including the colon, but excluding
              Message 6 of 7 , Dec 10, 2013
              • 0 Attachment
                On Sunday, January 6, 2013 2:07:39 PM UTC+1, Christian Brabandt wrote:

                >
                > What exactly do you consider a bug? Using p is a pretty basic action and
                >
                > changing the cursor position will be a backwards incompatible change and
                >
                > will probably break many scripts, macros and maps, thus it is not very
                >
                > likely, that this behaviour is going to be "fixed", especially since
                >
                > nobody has complained until now.

                Hmm "nobody has complained"? Interesting. Maybe i would have complained, but i've decided instead to remap *all* keys (including the colon, but excluding <Esc>) and use different set of default functions to make it less painful :) (IMO). I guess people do not complain about Vim, they just remap.

                Best regards,

                Alexey.

                --
                --
                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.
              • Alexey
                As i wrote in https://groups.google.com/forum/#!topic/vim_use/cDXHgO5iBfI the thing that surprised me the most was that the behavior changes depending on
                Message 7 of 7 , Dec 10, 2013
                • 0 Attachment
                  As i wrote in https://groups.google.com/forum/#!topic/vim_use/cDXHgO5iBfI
                  the thing that surprised me the most was that the behavior changes depending on whether there are line breaks in the pasted text.

                  Alexey.

                  P.S. About my previous comment: i've remembered that actually i've slightly remapped <Esc> too.

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