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

Re: Patch 7.3.879

Expand Messages
  • glts
    ... That s fair. If you re interested, I wrote a test for this problem, which passes after patch 7.3.879. I added the test case to the new test94.in that I
    Message 1 of 5 , Apr 6, 2013
    • 0 Attachment
      On Sat, Apr 6, 2013 at 1:58 PM, Bram Moolenaar <Bram@...> wrote:
      >
      > David Bürgin wrote:
      >
      >> On Fri, Apr 5, 2013 at 5:43 PM, Bram Moolenaar <Bram@...> wrote:
      >> >
      >> > Patch 7.3.879
      >> > Problem: When using an ex command in operator pending mode, using Esc to
      >> > abort the command still executes the operator. (David Bürgin)
      >> > Solution: Clear the operator when the ex command fails. (Christian Brabandt)
      >> > Files: src/normal.c
      >>
      >> I don't know if you saw it but I posted an improved version of this
      >> patch -- or so I thought.
      >>
      >> https://groups.google.com/d/msg/vim_dev/rHP4zUKwp2g/y3qVRwRktHMJ
      >>
      >> I pointed to two flaws in the current patch:
      >>
      >> - There is a redundant call to clearop() when cancelling ordinary colon
      >> commands, e.g. ":call <Esc>".
      >
      > clearop() is a very simple function, it's not really worth the effort to
      > call it only when needed.
      >
      >> - When cmd_result == FAIL and did_emsg == TRUE only clearop() will be
      >> called when instead clearopbeep() is the intended call. To be sure,
      >> currently this only happens when there's an out of memory error in
      >> ex_docmd.c#1055, but it's still not ideal.
      >
      > If did_emsg is TRUE a beep should already have happened, if it's needed.
      > The other clearopbeep() is when we detect a new error.

      That's fair.

      If you're interested, I wrote a test for this problem, which passes
      after patch 7.3.879.

      I added the test case to the new test94.in that I proposed in another
      recent message. If you plan to include the test, then please use this
      updated version.

      Thanks.

      --
      --
      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.
    • Bram Moolenaar
      ... Thanks, it s always good to test things that were broken. It may break again. -- In a world without fences, who needs Gates and Windows? /// Bram
      Message 2 of 5 , Apr 6, 2013
      • 0 Attachment
        David Bürgin wrote:

        > On Sat, Apr 6, 2013 at 1:58 PM, Bram Moolenaar <Bram@...> wrote:
        > >
        > > David Bürgin wrote:
        > >
        > >> On Fri, Apr 5, 2013 at 5:43 PM, Bram Moolenaar <Bram@...> wrote:
        > >> >
        > >> > Patch 7.3.879
        > >> > Problem: When using an ex command in operator pending mode, using Esc to
        > >> > abort the command still executes the operator. (David Bürgin)
        > >> > Solution: Clear the operator when the ex command fails. (Christian Brabandt)
        > >> > Files: src/normal.c
        > >>
        > >> I don't know if you saw it but I posted an improved version of this
        > >> patch -- or so I thought.
        > >>
        > >> https://groups.google.com/d/msg/vim_dev/rHP4zUKwp2g/y3qVRwRktHMJ
        > >>
        > >> I pointed to two flaws in the current patch:
        > >>
        > >> - There is a redundant call to clearop() when cancelling ordinary colon
        > >> commands, e.g. ":call <Esc>".
        > >
        > > clearop() is a very simple function, it's not really worth the effort to
        > > call it only when needed.
        > >
        > >> - When cmd_result == FAIL and did_emsg == TRUE only clearop() will be
        > >> called when instead clearopbeep() is the intended call. To be sure,
        > >> currently this only happens when there's an out of memory error in
        > >> ex_docmd.c#1055, but it's still not ideal.
        > >
        > > If did_emsg is TRUE a beep should already have happened, if it's needed.
        > > The other clearopbeep() is when we detect a new error.
        >
        > That's fair.
        >
        > If you're interested, I wrote a test for this problem, which passes
        > after patch 7.3.879.
        >
        > I added the test case to the new test94.in that I proposed in another
        > recent message. If you plan to include the test, then please use this
        > updated version.

        Thanks, it's always good to test things that were broken. It may break
        again.

        --
        In a world without fences, who needs Gates and Windows?

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

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