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

Re: virtualedit cursor movement and 'x' bug

Expand Messages
  • Matthias Kramm
    ... This would mean we hunk some code where x is translated into dl, because this is the reason of failure when x get s pressed in virtual-mode at the end of a
    Message 1 of 11 , Oct 2, 2000
    View Source
    • 0 Attachment
      On Sun, Oct 01, 2000 at 03:33:05PM +0200, Bram Moolenaar wrote:

      > > PS: Maybe an extra flag, like started_delete_when_w_coladd_was_not_zero
      > > would do?
      >
      > I would rather deal with the problem either where it is caused or where we run
      > into it. I know this won't be easy to figure out, and will be work. But
      > since virtual editing is a generic feature we better make it work in a clean
      > way.

      This would mean we hunk some code where x is translated into dl, because this
      is the reason of failure when x get's pressed in virtual-mode at the end of
      a line: d? deletes text of the motion ?, which is zero here (only coladd
      get's modified) Something like

      if(ve-is-on and end-of-line) then
      don't translate x into dl but into... [?]

      Any Ideas?

      Greetings

      Matthias
    • Bram Moolenaar
      ... What should x really do in virtual-edit mode? Nothing, probably. Doesn t the problem exist because coladvance_force() adds spaces, even though we don t
      Message 2 of 11 , Oct 2, 2000
      View Source
      • 0 Attachment
        Matthias Kramm wrote:

        > This would mean we hunk some code where x is translated into dl, because this
        > is the reason of failure when x get's pressed in virtual-mode at the end of
        > a line: d? deletes text of the motion ?, which is zero here (only coladd
        > get's modified) Something like
        >
        > if(ve-is-on and end-of-line) then
        > don't translate x into dl but into... [?]

        What should "x" really do in virtual-edit mode? Nothing, probably.

        Doesn't the problem exist because coladvance_force() adds spaces, even though
        we don't need them, since nothing is going to be deleted? Perhaps the spaces
        should not be added when the operator is a no-op (or will fail).

        --
        hundred-and-one symptoms of being an internet addict:
        133. You communicate with people on other continents more than you
        do with your own neighbors.

        /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
        \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
      • Matthias Kramm
        ... Yes. As x means dl, it _should_ do nothing. Anyway, we _want_ it to delete the last character of a line if the cursor is on that character. (this is
        Message 3 of 11 , Oct 2, 2000
        View Source
        • 0 Attachment
          >
          > What should "x" really do in virtual-edit mode? Nothing, probably.
          >

          Yes. As "x" means dl, it _should_ do nothing.
          Anyway, we _want_ it to delete the last character of a line if the cursor
          is on that character. (this is somehow incorrect, because the l motion
          wouldn't change the cursor position, so the dl should do nothing)

          > Doesn't the problem exist because coladvance_force() adds spaces, even though
          > we don't need them, since nothing is going to be deleted? Perhaps the spaces
          > should not be added when the operator is a no-op (or will fail).

          Actually, no coladvance_force-s take place, at least none that change the
          text (the cursor is on a non-virtual position, being on the last character
          of a line)
          The problem is the one mentioned above: dl would do nothing, but is
          expected to delete one character. That's why I made deletes of one char out of
          deletes of zero chars.

          Greetings

          Matthias
        Your message has been successfully submitted and would be delivered to recipients shortly.