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

More virtualedit (using rectangular selection) oddities

Expand Messages
  • Mark Waggoner
    I can t follow the code well enough to figure out where these are happening. These are all with set virtualedit=all and are all related to rectangular visual
    Message 1 of 10 , Sep 25, 2000
    • 0 Attachment
      I can't follow the code well enough to figure out where these are
      happening. These are all with set virtualedit=all and are all related
      to rectangular visual selection.

      1. Start a rectangular visual select (Ctrl-V) in virtual space, move
      down a few lines into non-virtual space, maybe over a space, and do
      a yank (y). If you paste this somewhere else, you'll find that the
      yanked text does not match what was visually highlighted.

      2. Given the same scenario as above, when you do the yank (y), the
      cursor is placed back into non-virtual space on the line you
      started on. If you do the same thing starting in non-virtual
      space, the cursor returns to where the visual select started.

      3. Select a rectangular block (not using virtual space) and then paste
      (p) it into virtual space (with the cursor in virtual space).
      Instead of being pasted after the cursor position, it is pasted
      before the cursor position. Paste with P puts it two spaces back.

      4. Start a rectangular visual select with Ctrl-V, move down a few
      lines and then use $ to select to the end of the line. It will
      behave differently with virtualedit on than with it off. With
      virtualedit on, The selection will not include intervening lines
      that are longer than the current line.

      --------------------------------------------------------------------------
      Mark Waggoner waggoner@... (503) 712-3335
      Three singing pigs say "La La La!"
    • Matthias Kramm
      ... yepp. fixed. see patch below. (to be honest i didn t fully understand what i did there, having not much knowledge about the visual-selection code, but it s
      Message 2 of 10 , Oct 1, 2000
      • 0 Attachment
        On Mon, Sep 25, 2000 at 04:06:35PM -0700, Mark Waggoner wrote:
        >
        > I can't follow the code well enough to figure out where these are
        > happening. These are all with set virtualedit=all and are all related
        > to rectangular visual selection.
        >
        > 1. Start a rectangular visual select (Ctrl-V) in virtual space, move
        > down a few lines into non-virtual space, maybe over a space, and do
        > a yank (y). If you paste this somewhere else, you'll find that the
        > yanked text does not match what was visually highlighted.

        yepp. fixed. see patch below.
        (to be honest i didn't fully understand what i did there, having not much
        knowledge about the visual-selection code, but it's just one line and
        it works...:) )

        >
        > 2. Given the same scenario as above, when you do the yank (y), the
        > cursor is placed back into non-virtual space on the line you
        > started on. If you do the same thing starting in non-virtual
        > space, the cursor returns to where the visual select started.

        yes. the cursor jumps to the next real text character (i.e., non virtual
        position) (marks do so too, btw)
        don't know exactly how to change it in this case. maybe something in
        do_pending_operator?
        (after all, we should have the correct cursor column to jump to in
        curbuf->b_visual_start_coladd)

        >
        > 4. Start a rectangular visual select with Ctrl-V, move down a few
        > lines and then use $ to select to the end of the line. It will
        > behave differently with virtualedit on than with it off. With
        > virtualedit on, The selection will not include intervening lines
        > that are longer than the current line.
        >

        if I got you right, this is similar to 1 (blockmode visual yank changes the
        cursor from the virtual position to the corresponding non-virtual position
        before the yank, resulting in a wrong selection). see patch.

        Greetings

        Matthias
      • Matthias Kramm
        ... fixed. see patch below. Greetings Matthias ... +++ ops.c Sun Oct 1 12:04:55 2000 @@ -2501,7 +2501,9 @@ #ifdef FEAT_VIRTUALEDIT if (ve_all &&
        Message 3 of 10 , Oct 1, 2000
        • 0 Attachment
          On Mon, Sep 25, 2000 at 04:06:35PM -0700, Mark Waggoner wrote:

          > 3. Select a rectangular block (not using virtual space) and then paste
          > (p) it into virtual space (with the cursor in virtual space).
          > Instead of being pasted after the cursor position, it is pasted
          > before the cursor position. Paste with P puts it two spaces back.
          >

          fixed. see patch below.

          Greetings

          Matthias
        • Bram Moolenaar
          ... I certainly hope you take some time to figure out how it works! Trial-and-error is not appreciated... ... The problem here is that a yank operation
          Message 4 of 10 , Oct 1, 2000
          • 0 Attachment
            Matthias Kramm wrote:

            > yepp. fixed. see patch below.
            > (to be honest i didn't fully understand what i did there, having not much
            > knowledge about the visual-selection code, but it's just one line and
            > it works...:) )

            I certainly hope you take some time to figure out how it works!
            Trial-and-error is not appreciated...

            > > 2. Given the same scenario as above, when you do the yank (y), the
            > > cursor is placed back into non-virtual space on the line you
            > > started on. If you do the same thing starting in non-virtual
            > > space, the cursor returns to where the visual select started.
            >
            > yes. the cursor jumps to the next real text character (i.e., non virtual
            > position) (marks do so too, btw)
            > don't know exactly how to change it in this case. maybe something in
            > do_pending_operator?
            > (after all, we should have the correct cursor column to jump to in
            > curbuf->b_visual_start_coladd)

            The problem here is that a yank operation normally doesn't change the text.
            But the way virtual-editing was implemented it inserts extra spaces when doing
            an operator, also with yank.

            Perhaps the spaces should be removed again after yanking, and w_coladd set to
            its old value. Then we yank the right text, the text isn't modified and the
            cursor can stay in the same position.

            An alternative is not to add spaces for a yank operation, and handle it
            completely in the yank function. Then w_coladd doesn't need to change and the
            cursor stays where it is.

            I'll include the patch, although it looks like it's still wrong.

            --
            hundred-and-one symptoms of being an internet addict:
            105. When someone asks you for your address, you tell them your URL.

            /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
            \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
          • Bram Moolenaar
            ... That works. One remaining problem: When doing P there is a trailing space in the line. -- hundred-and-one symptoms of being an internet addict: 106.
            Message 5 of 10 , Oct 1, 2000
            • 0 Attachment
              Matthias Kramm wrote:

              > On Mon, Sep 25, 2000 at 04:06:35PM -0700, Mark Waggoner wrote:
              >
              > > 3. Select a rectangular block (not using virtual space) and then paste
              > > (p) it into virtual space (with the cursor in virtual space).
              > > Instead of being pasted after the cursor position, it is pasted
              > > before the cursor position. Paste with P puts it two spaces back.
              >
              > fixed. see patch below.

              That works. One remaining problem: When doing "P" there is a trailing space
              in the line.

              --
              hundred-and-one symptoms of being an internet addict:
              106. When told to "go to your room" you inform your parents that you
              can't...because you were kicked out and banned.

              /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
              \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
            • Matthias Kramm
              ... pfffft... :) Well: the patch removed the coladvance_force, which was executed before at the end of a visual selection. because of this, we had a line the
              Message 6 of 10 , Oct 2, 2000
              • 0 Attachment
                On Sun, Oct 01, 2000 at 03:33:06PM +0200, Bram Moolenaar wrote:
                >
                > Matthias Kramm wrote:
                >
                > > yepp. fixed. see patch below.
                > > (to be honest i didn't fully understand what i did there, having not much
                > > knowledge about the visual-selection code, but it's just one line and
                > > it works...:) )
                >
                > I certainly hope you take some time to figure out how it works!
                > Trial-and-error is not appreciated...

                pfffft... :)

                Well: the patch removed the coladvance_force, which was executed before at
                the end of a visual selection. because of this, we had a line the size of
                the right down corner of the visual selection, and some nonsense in
                curbuf->b_visual_start/end_coladd. then we added those to the cursorpos, which
                was, due to the coladvance_force, already right, and so delivered wrong
                values to the code at about 1330 in normal.c which checks that the left
                upper corner is really left and the lower right corner is really right.
                Things got messed up, and block_prep got the wrong vpos's.
                Satisfied? :)

                Anyway, I spent my morning searching for a better way. The attached patch
                doesn't require the 2nd coladvance_force, fixes point 2 of Mark's list
                (jumping to the wrong position after jank), and also doesn't anymore insert
                spaces for yank.

                >
                > I'll include the patch, although it looks like it's still wrong.
                >

                No it's not. :)
                Actually, the last patch is a subset of this patch.

                Greetings

                Matthias
              • Bram Moolenaar
                ... Good, I ll include this patch. With a few more #ifdef FEAT_VIRTUALEDIT added. -- hundred-and-one symptoms of being an internet addict: 132. You come back
                Message 7 of 10 , Oct 2, 2000
                • 0 Attachment
                  Matthias Kramm wrote:

                  > Anyway, I spent my morning searching for a better way. The attached patch
                  > doesn't require the 2nd coladvance_force, fixes point 2 of Mark's list
                  > (jumping to the wrong position after jank), and also doesn't anymore insert
                  > spaces for yank.

                  Good, I'll include this patch. With a few more #ifdef FEAT_VIRTUALEDIT added.

                  --
                  hundred-and-one symptoms of being an internet addict:
                  132. You come back and check this list every half-hour.

                  /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                  \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                • Mark Waggoner
                  ... Virtual edit testing report #18252 Matthais latest patches have improved things. Thanks! I m finding some more oddities. Many of them revolve around a
                  Message 8 of 10 , Oct 3, 2000
                  • 0 Attachment
                    On Mon, 2 Oct 2000, Bram Moolenaar wrote:

                    > Matthias Kramm wrote:
                    >
                    > > Anyway, I spent my morning searching for a better way. The attached patch
                    > > doesn't require the 2nd coladvance_force, fixes point 2 of Mark's list
                    > > (jumping to the wrong position after jank), and also doesn't anymore insert
                    > > spaces for yank.
                    >
                    > Good, I'll include this patch. With a few more #ifdef FEAT_VIRTUALEDIT added.

                    Virtual edit testing report #18252

                    Matthais' latest patches have improved things. Thanks!

                    I'm finding some more oddities. Many of them revolve around a
                    fundamental question of how vim should behave when virtual editing is
                    turned on. It seems like it should always behave as if there were
                    spaces up to and including the current cursor position when the cursor
                    is in virtual space. This leads to situations where actions that
                    would not normally have changed the file might now change it (e.g.
                    selecting or yanking starting in virtual space). Alternatively, it
                    could behave (as it often does now) as if the cursor is on the last
                    real character of the line. This leads to some counter-intuitive
                    behavior, but avoids changing the file based on actions that you
                    wouldn't expect to change it.

                    Any comments on how, fundamentally, we should expect virtual editing
                    to behave?


                    On to the oddities....

                    I'll use this sample text for some of the examples below.

                    0. Short
                    1. This is a block of test text
                    2. This is a block of test text
                    3. This is a block of test text
                    4. This is a longer line in the block test area
                    5. This is a block of test text
                    6. Short line
                    7. This is a block of test text



                    Just to make sure.... Here's what I see regarding my previous reports:

                    1. Start a rectangular visual select (Ctrl-V) in virtual space, move
                    down a few lines into non-virtual space, maybe over a space, and do
                    a yank (y). If you paste this somewhere else, you'll find that the
                    yanked text does not match what was visually highlighted.

                    2. Given the same scenario as above, when you do the yank (y), the
                    cursor is placed back into non-virtual space on the line you
                    started on. If you do the same thing starting in non-virtual
                    space, the cursor returns to where the visual select started.

                    Both 1 and 2 are fixed. However, I've found that if I do something
                    very similar, but instead of moving down to make the rectangular
                    selection, I move up, it still gets confused. Using the sample text
                    above, here's the sequence:
                    Cursor off the end of line 5, Ctrl-V, move up and to the right to
                    select a block
                    a. Use "y" to yank and cursor goes strange places.
                    b. Yanked text is incorrect. (see by "p"utting it somewhere)

                    3. Select a rectangular block (not using virtual space) and then paste
                    (p) it into virtual space (with the cursor in virtual space).
                    Instead of being pasted after the cursor position, it is pasted
                    before the cursor position. Paste with P puts it two spaces back.

                    Not yet fixed

                    4. Start a rectangular visual select with Ctrl-V, move down a few
                    lines and then use $ to select to the end of the line. It will
                    behave differently with virtualedit on than with it off. With
                    virtualedit on, The selection will not include intervening lines
                    that are longer than the current line.

                    Not yet fixed


                    New stuff!

                    5. 'v' selection is kind of strange. When in virtual space, pressing
                    'v' will select the last character on the line, though the cursor
                    remains in virtual space. What should it do here? I think people
                    might expect it to extend the current line out to the cursor
                    position and start selection there, but I don't really think
                    selection should modify the line. Maybe it should do what it is
                    doing, but move the cursor back to the end of the line?

                    6. 'p' of regular text (not blockwise or line-wise) in virtual space
                    doesn't behave as expected. Example:
                    Put cursor on start of the word "Short" in line 0
                    Type "yw" to yank the word
                    Move cursor to virtual space past end of line 0
                    Type "p" to put. I would expect it to add spaces out to the
                    current cursor position and then do the put, but it puts it on
                    the end of the line without spaces.

                    7. (Probably same as 4) Using '$' behaves differently.
                    Example:
                    Cursor in a short line
                    type '$' to go to the end of the line
                    type 'j' to move down to longer lines
                    With ve=all, the cursor remains in the same column as the end of
                    the short line.
                    With ve= , the cursor goes to the end of each line it comes to.

                    8. Using "R" in virtual space moves back one character before starting
                    the replacement.

                    9. Using "C" in virtual space moves back to the end of the current
                    line to start changing rather than inserting spaces up to the
                    current point and then changing.


                    My apologies for reporting but not fixing bugs. I appreciate the work
                    being put into this feature very much. There are times (though not
                    extremely common) when virtual editing is very helpful. I also think
                    there are many new users who get annoyed by vim's inability to move
                    the cursor beyond the end of the line. On the other hand, they may
                    be better served by being forced to adjust their attitudes than by
                    being coddled with a virtualedit feature. :^)


                    (This signature is NOT meant as a comment on virtual editing!)

                    --------------------------------------------------------------------------
                    Mark Waggoner waggoner@... (503) 712-3335
                    And this mess is so big and so deep and so tall,
                    we can not pick it up. There is no way at all!
                  • Matthias Kramm
                    (this is a no-patch mail, just some remarks... :) ) ... I think it should simply implement some intuitive cursor movement, known from some dos-world text
                    Message 9 of 10 , Oct 3, 2000
                    • 0 Attachment
                      (this is a no-patch mail, just some remarks... :) )

                      On Tue, Oct 03, 2000 at 12:41:29PM -0700, Mark Waggoner wrote:
                      > ...
                      >
                      > I'm finding some more oddities. Many of them revolve around a
                      > fundamental question of how vim should behave when virtual editing is
                      > turned on. It seems like it should always behave as if there were
                      > spaces up to and including the current cursor position when the cursor
                      > is in virtual space. This leads to situations where actions that
                      > would not normally have changed the file might now change it (e.g.
                      > selecting or yanking starting in virtual space). Alternatively, it
                      > could behave (as it often does now) as if the cursor is on the last
                      > real character of the line. This leads to some counter-intuitive
                      > behavior, but avoids changing the file based on actions that you
                      > wouldn't expect to change it.
                      >

                      I think it should simply implement some "intuitive" cursor movement, known
                      from some dos-world text editors, e.g. the Borland-GUI's or Aurora,
                      where you don't care about whether there are spaces and tabs, but simply
                      work with your text, not having to wonder about strange cursor-movement
                      just because there was some unexpected (and invisible) tab or space floating
                      around.
                      Therefore, virtual editing only makes sense if whitespace just fills the
                      gaps (like in c, java etc.) and has no deeper syntactical meaning.
                      (like in makefiles)
                      This leads to the question whether careless handling of whitespaces in the
                      files should be allowed- they are not important to the user, according to
                      the things stated above. (and he wouldn't be using virtualediting, if they
                      were)
                      Actually, first versions of virtualedit did even change whitespaces by
                      browsing around.

                      > Both 1 and 2 are fixed. However, I've found that if I do something
                      > very similar, but instead of moving down to make the rectangular
                      > selection, I move up, it still gets confused. Using the sample text
                      > above, here's the sequence:
                      > Cursor off the end of line 5, Ctrl-V, move up and to the right to
                      > select a block
                      > a. Use "y" to yank and cursor goes strange places.
                      > b. Yanked text is incorrect. (see by "p"utting it somewhere)
                      >
                      > 3. Select a rectangular block (not using virtual space) and then paste
                      > (p) it into virtual space (with the cursor in virtual space).
                      > Instead of being pasted after the cursor position, it is pasted
                      > before the cursor position. Paste with P puts it two spaces back.
                      >
                      > Not yet fixed

                      They should be fixed by now. Check out the patches flying around. (they
                      should be in the list, in some replys to Bram)

                      > 7. (Probably same as 4) Using '$' behaves differently.
                      > Example:
                      > Cursor in a short line
                      > type '$' to go to the end of the line
                      > type 'j' to move down to longer lines
                      > With ve=all, the cursor remains in the same column as the end of
                      > the short line.
                      > With ve= , the cursor goes to the end of each line it comes to.

                      (1) One goal of the implementation of virtualediting was
                      a) pressing the "cursor up"-key moves the cursor one character up.
                      b) pressing the "cursor down"-key moves the cursor one character down.
                      c) pressing the "cursor left"-key moves the cursor one character left.
                      d) pressing the "cursor right"-key moves the cursor one character right.
                      d always, a and b always unless you are on the first/last line of the file,
                      c on all columns except 1.

                      This should explain 7. which works just as intended. What _you_ do want from
                      ve in this case that pressing "cursor down" moves the cursor far to the
                      right or left. (_and_ one line down, ok)

                      >
                      > My apologies for reporting but not fixing bugs. I appreciate the work
                      > being put into this feature very much. There are times (though not
                      > extremely common) when virtual editing is very helpful. I also think
                      > there are many new users who get annoyed by vim's inability to move
                      > the cursor beyond the end of the line. On the other hand, they may
                      > be better served by being forced to adjust their attitudes than by
                      > being coddled with a virtualedit feature. :^)
                      >

                      Funny though- when I came to vim, the first thing which was bothering me
                      was the non-virtual-editing, i.e. the cursor jumping around when pressing
                      "cursor down", getting stuck at the end of a line, refusing to go to the
                      first column when there was a tab etc.
                      So I did this virtualediting-patch. Anyway, since being forced to use a
                      non-ve-patched vim sometimes, I suddenly switched to a "full-time-non-ve-user",
                      that is, I don't use this feature anymore.
                      I agree with Bram at last: ve is useful for using visual-block-select and
                      editing tables, and maybe for novices, like you said...

                      >
                      > (This signature is NOT meant as a comment on virtual editing!)

                      you sure? never saw that one before in a mail of yours... :)

                      Greetings

                      Matthias
                    • Bram Moolenaar
                      ... I would say that virtual editing means the cursor is not on a real character. Moving around works on screen characters instead of file characters. When
                      Message 10 of 10 , Oct 4, 2000
                      • 0 Attachment
                        Mark Waggoner wrote:

                        > I'm finding some more oddities. Many of them revolve around a
                        > fundamental question of how vim should behave when virtual editing is
                        > turned on. It seems like it should always behave as if there were
                        > spaces up to and including the current cursor position when the cursor
                        > is in virtual space. This leads to situations where actions that
                        > would not normally have changed the file might now change it (e.g.
                        > selecting or yanking starting in virtual space). Alternatively, it
                        > could behave (as it often does now) as if the cursor is on the last
                        > real character of the line. This leads to some counter-intuitive
                        > behavior, but avoids changing the file based on actions that you
                        > wouldn't expect to change it.

                        I would say that virtual editing means the cursor is not on a real character.
                        Moving around works on screen characters instead of file characters.
                        When making changes spaces might need to be inserted to have it work at the
                        right position, since changes can't work on virtual characters.
                        I still think that yanking should not insert spaces in the text. But the
                        yanked text may include some extra spaces.

                        > On to the oddities....
                        >
                        > I'll use this sample text for some of the examples below.
                        >
                        > 0. Short
                        > 1. This is a block of test text
                        > 2. This is a block of test text
                        > 3. This is a block of test text
                        > 4. This is a longer line in the block test area
                        > 5. This is a block of test text
                        > 6. Short line
                        > 7. This is a block of test text
                        >
                        > Both 1 and 2 are fixed. However, I've found that if I do something
                        > very similar, but instead of moving down to make the rectangular
                        > selection, I move up, it still gets confused. Using the sample text
                        > above, here's the sequence:
                        > Cursor off the end of line 5, Ctrl-V, move up and to the right to
                        > select a block
                        > a. Use "y" to yank and cursor goes strange places.
                        > b. Yanked text is incorrect. (see by "p"utting it somewhere)

                        Yes, I see this problem too, also after including the latest patches.

                        > 3. Select a rectangular block (not using virtual space) and then paste
                        > (p) it into virtual space (with the cursor in virtual space).
                        > Instead of being pasted after the cursor position, it is pasted
                        > before the cursor position. Paste with P puts it two spaces back.
                        >
                        > Not yet fixed

                        This is fixed for me. But "P" leaves a space at the end of the line.

                        > 4. Start a rectangular visual select with Ctrl-V, move down a few
                        > lines and then use $ to select to the end of the line. It will
                        > behave differently with virtualedit on than with it off. With
                        > virtualedit on, The selection will not include intervening lines
                        > that are longer than the current line.
                        >
                        > Not yet fixed

                        Right.

                        > New stuff!
                        >
                        > 5. 'v' selection is kind of strange. When in virtual space, pressing
                        > 'v' will select the last character on the line, though the cursor
                        > remains in virtual space. What should it do here? I think people
                        > might expect it to extend the current line out to the cursor
                        > position and start selection there, but I don't really think
                        > selection should modify the line. Maybe it should do what it is
                        > doing, but move the cursor back to the end of the line?

                        I think that pressing 'v' marks the start of the selection. Thus the
                        selection should start in virtual space. This might not be useful when
                        beyond the end of a line, but it is when halfway a TAB. Only when you perform
                        some operation on the Visual area there might need to be some spaces added to
                        the text, but just selecting shouldn't do that.

                        > 6. 'p' of regular text (not blockwise or line-wise) in virtual space
                        > doesn't behave as expected. Example:
                        > Put cursor on start of the word "Short" in line 0
                        > Type "yw" to yank the word
                        > Move cursor to virtual space past end of line 0
                        > Type "p" to put. I would expect it to add spaces out to the
                        > current cursor position and then do the put, but it puts it on
                        > the end of the line without spaces.

                        Yep, see this too.

                        > 7. (Probably same as 4) Using '$' behaves differently.
                        > Example:
                        > Cursor in a short line
                        > type '$' to go to the end of the line
                        > type 'j' to move down to longer lines
                        > With ve=all, the cursor remains in the same column as the end of
                        > the short line.
                        > With ve= , the cursor goes to the end of each line it comes to.

                        Well, what would you expect? Once you start virtual editing the cursor does
                        move differently. Whether this also means moving up/down now keeps the screen
                        column or not is a choice. It's probably difficult to stay at the last char
                        of a line after a "$" command. At least it would look strange.

                        > 8. Using "R" in virtual space moves back one character before starting
                        > the replacement.

                        Yep.

                        > 9. Using "C" in virtual space moves back to the end of the current
                        > line to start changing rather than inserting spaces up to the
                        > current point and then changing.

                        Yep. And when the cursor is halfway a TAB it also doesn't work right.

                        > My apologies for reporting but not fixing bugs. I appreciate the work
                        > being put into this feature very much. There are times (though not
                        > extremely common) when virtual editing is very helpful. I also think
                        > there are many new users who get annoyed by vim's inability to move
                        > the cursor beyond the end of the line. On the other hand, they may
                        > be better served by being forced to adjust their attitudes than by
                        > being coddled with a virtualedit feature. :^)

                        It's good to find the problems with virtual editing. I'm quite sure there
                        will be more. Hopefully we can find some basic solutions, so that we fix
                        many bugs at the same time.

                        --
                        hundred-and-one symptoms of being an internet addict:
                        167. You have more than 100 websites in your Bookmark.

                        /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                        \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                      Your message has been successfully submitted and would be delivered to recipients shortly.