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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.