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

Bug: Ex command after "motion force" cannot be aborted properly

Expand Messages
  • glts
    In Operator-pending mode it is possible to use Ex commands to move the cursor. When editing the command-line in this situation, normally aborts the whole
    Message 1 of 9 , Mar 27, 2013
    • 0 Attachment
      In Operator-pending mode it is possible to use Ex commands to move the
      cursor. When editing the command-line in this situation, <Esc> normally
      aborts the whole operation. For example, in normal mode:

      d:call<Esc>

      This command has no effect.

      But when a "motion force" has been given before entering the
      command-line, the command cannot be aborted. To reproduce, again in
      normal mode:

      dv:call<Esc>
      dV:call<Esc>

      These commands delete one character and one line respectively.

      David Bürgin

      --
      --
      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.
    • Christian Brabandt
      Hi glts! ... But it doesn t really abort. ... Here is a patch, that checks, whether the ex command could be executed and also whether the command possibly
      Message 2 of 9 , Mar 27, 2013
      • 0 Attachment
        Hi glts!

        On Mi, 27 Mär 2013, glts wrote:

        > In Operator-pending mode it is possible to use Ex commands to move the
        > cursor. When editing the command-line in this situation, <Esc> normally
        > aborts the whole operation. For example, in normal mode:
        >
        > d:call<Esc>
        >
        > This command has no effect.

        But it doesn't really abort.

        >
        > But when a "motion force" has been given before entering the
        > command-line, the command cannot be aborted. To reproduce, again in
        > normal mode:
        >
        > dv:call<Esc>
        > dV:call<Esc>
        >
        > These commands delete one character and one line respectively.

        Here is a patch, that checks, whether the ex command could be executed
        and also whether the command possibly generated an error.

        regards,
        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

        ---
        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.
      • glts
        Christian, thanks for looking into this. ... I don t understand. The command is cancelled silently, just as it is when you cancel other Operator-pending
        Message 3 of 9 , Mar 27, 2013
        • 0 Attachment
          Christian, thanks for looking into this.

          On Wed, Mar 27, 2013 at 4:01 PM, Christian Brabandt <cblists@...> wrote:
          > On Mi, 27 Mär 2013, glts wrote:
          >> d:call<Esc>
          >>
          >> This command has no effect.
          >
          > But it doesn't really abort.

          I don't understand. The command is cancelled silently, just as it is
          when you cancel other Operator-pending commands, e.g. "d3<Esc>". This is
          what I would expect.

          > Here is a patch, that checks, whether the ex command could be executed
          > and also whether the command possibly generated an error.

          I don't think this is the right solution. The behaviour should be the
          same as for other Operator-pending commands: "d<Esc>", "dv<Esc>",
          "d:<Esc>". This isn't erroneous input and we don't want Vim to beep.

          David

          --
          --
          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.
        • Christian Brabandt
          ... d:call (Note the error message). regards, Christian -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply
          Message 4 of 9 , Mar 27, 2013
          • 0 Attachment
            On Wed, March 27, 2013 17:18, glts wrote:
            > Christian, thanks for looking into this.
            >
            > On Wed, Mar 27, 2013 at 4:01 PM, Christian Brabandt <cblists@...>
            > wrote:
            >> On Mi, 27 Mär 2013, glts wrote:
            >>> d:call<Esc>
            >>>
            >>> This command has no effect.
            >>
            >> But it doesn't really abort.
            >
            > I don't understand. The command is cancelled silently, just as it is
            > when you cancel other Operator-pending commands, e.g. "d3<Esc>". This is
            > what I would expect.

            Not it isn't. Simple case:
            :h
            d:call<esc>

            (Note the error message).

            regards,
            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

            ---
            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.
          • glts
            I still don t think it should be an error. Sometimes when you start typing d3... you realize you wanted change instead of delete , so you press and
            Message 5 of 9 , Mar 27, 2013
            • 0 Attachment
              I still don't think it should be an error. Sometimes when you start
              typing "d3..." you realize you wanted "change" instead of "delete", so
              you press <Esc> and start again.

              For me, "d:call <Esc>" is the same thing. Perhaps you want to use a
              custom function but you forgot to source the relevant file, so you
              cancel and start again. I don't feel this is an error. What do you
              think?

              On Wed, Mar 27, 2013 at 5:35 PM, Christian Brabandt <cblists@...> wrote:
              > On Wed, March 27, 2013 17:18, glts wrote:
              >> On Wed, Mar 27, 2013 at 4:01 PM, Christian Brabandt <cblists@...>
              >> wrote:
              >>> On Mi, 27 Mär 2013, glts wrote:
              >>>> d:call<Esc>
              >>>>
              >>>> This command has no effect.
              >>>
              >>> But it doesn't really abort.
              >>
              >> I don't understand. The command is cancelled silently, just as it is
              >> when you cancel other Operator-pending commands, e.g. "d3<Esc>". This is
              >> what I would expect.
              >
              > Not it isn't. Simple case:
              > :h
              > d:call<esc>
              >
              > (Note the error message).

              Oh right, I didn't catch that. All the more reason to sort out the root
              cause.

              --
              --
              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.
            • Christian Brabandt
              Hi glts! ... Ok, what do you think of this updated patch? regards, Christian -- Verstehen sie etwas vom Theater? Ja, wenn laut genug gesprochen wird. --
              Message 6 of 9 , Mar 27, 2013
              • 0 Attachment
                Hi glts!

                On Mi, 27 Mär 2013, glts wrote:

                > I still don't think it should be an error. Sometimes when you start
                > typing "d3..." you realize you wanted "change" instead of "delete", so
                > you press <Esc> and start again.
                >
                > For me, "d:call <Esc>" is the same thing. Perhaps you want to use a
                > custom function but you forgot to source the relevant file, so you
                > cancel and start again. I don't feel this is an error. What do you
                > think?

                Ok, what do you think of this updated patch?

                regards,
                Christian
                --
                "Verstehen sie etwas vom Theater?"
                "Ja, wenn laut genug gesprochen wird."

                --
                --
                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.
              • glts
                Christian, ... Won t there be a redundant call to clearop() now when cancelling ordinary Ex commands? I suppose it should work though. Thanks. Personally, I d
                Message 7 of 9 , Mar 27, 2013
                • 0 Attachment
                  Christian,

                  On Wed, Mar 27, 2013 at 11:01 PM, Christian Brabandt <cblists@...> wrote:
                  > Ok, what do you think of this updated patch?

                  Won't there be a redundant call to clearop() now when cancelling
                  ordinary Ex commands? I suppose it should work though. Thanks.

                  Personally, I'd rather not patch up bugs where the root cause is
                  unknown. In this case, the fact remains that "dv:<Esc>" deleted one
                  character and "dV:<Esc>" deleted one line, and "d:<Esc>" didn't. So I
                  would prefer to find out how this was possible -- maybe there's more.

                  --
                  --
                  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.
                • glts
                  Christian, ... You are of course correct. I now see that a motion given with an Ex command is exclusive by default, and v and V toggle inclusive/exclusive,
                  Message 8 of 9 , Mar 28, 2013
                  • 0 Attachment
                    Christian,

                    On Wed, Mar 27, 2013 at 11:01 PM, Christian Brabandt <cblists@...> wrote:
                    > Ok, what do you think of this updated patch?

                    You are of course correct.

                    I now see that a motion given with an Ex command is exclusive by
                    default, and "v" and "V" toggle inclusive/exclusive, and that is why
                    eventually the character or the line under the cursor are deleted.

                    I think your solution is fine, thanks a lot. I have attached a patch
                    that avoids calling clearop() when it isn't necessary and avoids calling
                    both clearop() and clearopbeep(), it's just a little bit more verbose.

                    --
                    --
                    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.
                  • glts
                    Sorry for being spammy: ... Nonsense. The patch avoids a) calling clearop() when it isn t necessary and b) *not beeping* when did_emsg == TRUE and cmd_result
                    Message 9 of 9 , Mar 28, 2013
                    • 0 Attachment
                      Sorry for being spammy:

                      On Thu, Mar 28, 2013 at 1:16 PM, glts <676c7473@...> wrote:
                      > On Wed, Mar 27, 2013 at 11:01 PM, Christian Brabandt <cblists@...> wrote:
                      >> Ok, what do you think of this updated patch?
                      >
                      > I think your solution is fine, thanks a lot. I have attached a patch
                      > that avoids calling clearop() when it isn't necessary and avoids calling
                      > both clearop() and clearopbeep(), it's just a little bit more verbose.

                      Nonsense. The patch avoids
                      a) calling clearop() when it isn't necessary and
                      b) *not beeping* when did_emsg == TRUE and cmd_result == FAIL

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