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

Re: virtualedit cursor movement and 'x' bug

Expand Messages
  • Matthias Kramm
    ... We can t test curwin- w_coladd, as it s zero when the above is executed, and oap- start and oap- end don t contain any coladd-information. To change this,
    Message 1 of 11 , Oct 1, 2000
    • 0 Attachment
      On Sat, Sep 30, 2000 at 09:29:14PM +0200, Bram Moolenaar wrote:
      > > +#ifdef FEAT_VIRTUALEDIT
      > > + if((oap->start.col == oap->end.col) &&
      > > + (oap->start.lnum == oap->end.lnum)
      > > + ) oap->end.col++;
      > > +#endif
      >
      > ...
      >
      > I can't add it just like this. It means that when FEAT_VIRTUALEDIT is defined
      > the operated area is never empty. I'm sure some commands will work
      > differently then.
      >
      > Shouldn't there be some test if w_coladd is non-zero here?
      >

      We can't test curwin->w_coladd, as it's zero when the above is executed,
      and oap->start and oap->end don't contain any coladd-information.
      To change this, we would have to add a coladd field to pos_t.

      Anyway, i don't see the problem with the above code, i.e. i can't think of
      a command which would behave differently.
      (It's just that i can't think of a useful command which deletes an empty
      region of text...)

      Greetings

      Matthias

      PS: Maybe an extra flag, like started_delete_when_w_coladd_was_not_zero would do?
    • Bram Moolenaar
      ... Hmm, that s indeed a problem. Since coladvance_force() has been used, spaces have been added to be able to position the cursor, and w_coladd was reset to
      Message 2 of 11 , Oct 1, 2000
      • 0 Attachment
        Matthias Kramm wrote:

        > On Sat, Sep 30, 2000 at 09:29:14PM +0200, Bram Moolenaar wrote:
        > > > +#ifdef FEAT_VIRTUALEDIT
        > > > + if((oap->start.col == oap->end.col) &&
        > > > + (oap->start.lnum == oap->end.lnum)
        > > > + ) oap->end.col++;
        > > > +#endif
        > >
        > > I can't add it just like this. It means that when FEAT_VIRTUALEDIT is
        > > defined the operated area is never empty. I'm sure some commands will
        > > work differently then.
        > >
        > > Shouldn't there be some test if w_coladd is non-zero here?
        >
        > We can't test curwin->w_coladd, as it's zero when the above is executed,
        > and oap->start and oap->end don't contain any coladd-information.
        > To change this, we would have to add a coladd field to pos_t.

        Hmm, that's indeed a problem. Since coladvance_force() has been used, spaces
        have been added to be able to position the cursor, and w_coladd was reset to
        zero.

        > Anyway, i don't see the problem with the above code, i.e. i can't think of
        > a command which would behave differently.
        > (It's just that i can't think of a useful command which deletes an empty
        > region of text...)

        Perhaps it just happens to work right now, but I find it basically wrong to
        change the text area for an operation just because the virtual-edit feature
        was enabled at compile time.

        For example, the oap->empty flag, which is set further down, will become
        invalid. Also, there is a difference when oap->inclusive is set. Having the
        start and end on the same character will then operate on one character. After
        your changes it will operator on two characters.

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

        --
        hundred-and-one symptoms of being an internet addict:
        104. When people ask about the Presidential Election you ask "Which country?"

        /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
        \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
      • 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 3 of 11 , Oct 2, 2000
        • 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 4 of 11 , Oct 2, 2000
          • 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 5 of 11 , Oct 2, 2000
            • 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.