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

why 'set confirm' is ignored for CTRL-^ (vs ":e #" which is OK)

Expand Messages
  • Yakov Lerner
    Why set confirm is ignored by CTRL-^ command ? Is it on purpose ? The :e # command does follow the set confirm as expected. It would be convenient if
    Message 1 of 10 , Sep 2, 2003
    • 0 Attachment
      Why 'set confirm' is ignored by CTRL-^ command ?
      Is it on purpose ?

      The ":e #" command does follow the "set confirm" as expected.

      It would be convenient if CTRL-^ also followed the
      'set confirm' setting, no ?

      Jacob Lerner
    • Bram Moolenaar
      ... It s because confirm only works for : commands. Not a very good reason... ... Try the patch below. The problem might be that the dialog pops up too
      Message 2 of 10 , Sep 2, 2003
      • 0 Attachment
        Yakov Lerner wrote:

        > Why 'set confirm' is ignored by CTRL-^ command ?
        > Is it on purpose ?

        It's because 'confirm' only works for ":" commands. Not a very good
        reason...

        > The ":e #" command does follow the "set confirm" as expected.
        >
        > It would be convenient if CTRL-^ also followed the
        > 'set confirm' setting, no ?

        Try the patch below. The problem might be that the dialog pops up too
        often then. This needs to be tested.

        *** ../vim-6.2.071/src/ex_cmds.c Sun Jul 27 14:57:01 2003
        --- src/ex_cmds.c Tue Sep 2 19:57:15 2003
        ***************
        *** 2464,2474 ****
        if (other && !forceit && curbuf->b_nwindows == 1 && !P_HID(curbuf)
        && curbufIsChanged() && autowrite(curbuf, forceit) == FAIL)
        {
        ! if (other)
        ! --no_wait_return;
        ! EMSG(_(e_nowrtmsg));
        ! retval = 2; /* file has been changed */
        ! goto theend;
        }
        if (other)
        --no_wait_return;
        --- 2464,2481 ----
        if (other && !forceit && curbuf->b_nwindows == 1 && !P_HID(curbuf)
        && curbufIsChanged() && autowrite(curbuf, forceit) == FAIL)
        {
        ! #if defined(FEAT_GUI_DIALOG) || defined(FEAT_CON_DIALOG)
        ! if (p_confirm && p_write)
        ! dialog_changed(curbuf, FALSE);
        ! if (curbufIsChanged())
        ! #endif
        ! {
        ! if (other)
        ! --no_wait_return;
        ! EMSG(_(e_nowrtmsg));
        ! retval = 2; /* file has been changed */
        ! goto theend;
        ! }
        }
        if (other)
        --no_wait_return;

        --
        "Never be afraid to tell the world who you are."
        -- Anonymous

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
      • Yakov Lerner
        ... Yes, this patch fixes it for CTRL-^. Now, I noticed that :bn command ignores the set confirm . While :n command does follow the set confirm . It
        Message 3 of 10 , Sep 3, 2003
        • 0 Attachment
          Bram Moolenaar wrote:
          > Yakov Lerner wrote:
          >
          >
          >>Why 'set confirm' is ignored by CTRL-^ command ?
          >>Is it on purpose ?
          >
          >
          > It's because 'confirm' only works for ":" commands. Not a very good
          > reason...
          >
          >
          >>The ":e #" command does follow the "set confirm" as expected.
          >>
          >>It would be convenient if CTRL-^ also followed the
          >>'set confirm' setting, no ?
          >
          >
          > Try the patch below. The problem might be that the dialog pops up too
          > often then. This needs to be tested.

          Yes, this patch fixes it for CTRL-^.

          Now, I noticed that ":bn" command ignores the 'set confirm'.

          While ":n" command does follow the "set confirm".

          It would be convenient if "set confirm" also worked for ":bn".


          Jacob Lerner
        • Antoine J. Mechelynck
          ... I would guess that the reason is that :bn never abandons a buffer, but just walks around the buffer list, so that no confirm is needed -- the previous
          Message 4 of 10 , Sep 3, 2003
          • 0 Attachment
            Yakov Lerner <yakov.lerner@...> wrote:
            > Bram Moolenaar wrote:
            > > Yakov Lerner wrote:
            > >
            > >
            > > > Why 'set confirm' is ignored by CTRL-^ command ?
            > > > Is it on purpose ?
            > >
            > >
            > > It's because 'confirm' only works for ":" commands. Not a very good
            > > reason...
            > >
            > >
            > > > The ":e #" command does follow the "set confirm" as expected.
            > > >
            > > > It would be convenient if CTRL-^ also followed the
            > > > 'set confirm' setting, no ?
            > >
            > >
            > > Try the patch below. The problem might be that the dialog pops up
            > > too often then. This needs to be tested.
            >
            > Yes, this patch fixes it for CTRL-^.
            >
            > Now, I noticed that ":bn" command ignores the 'set confirm'.
            >
            > While ":n" command does follow the "set confirm".
            >
            > It would be convenient if "set confirm" also worked for ":bn".
            >
            >
            > Jacob Lerner

            I would guess that the reason is that :bn never "abandons" a buffer, but
            just walks around the buffer list, so that no confirm is needed -- the
            previous buffer always stays loaded, only not visible, or at least not in
            that particular window. :next, OTOH, will fail if the current buffer cannot
            be "abandon"ed, thus if the buffer is modified it will trigger the "confirm"
            mechanism if enabled. See

            :help :bnext
            :help :next
            :help abandon

            Regards,
            Tony.
          • Antoine J. Mechelynck
            ... My big mouth... I should have not only read the help, but followed the links, before answering. :help buffer-! shows I was wrong. Regards, Tony.
            Message 5 of 10 , Sep 3, 2003
            • 0 Attachment
              Antoine J. Mechelynck <antoine.mechelynck@...> wrote:
              > Yakov Lerner <yakov.lerner@...> wrote:
              > > Bram Moolenaar wrote:
              > > > Yakov Lerner wrote:
              > > >
              > > >
              > > > > Why 'set confirm' is ignored by CTRL-^ command ?
              > > > > Is it on purpose ?
              > > >
              > > >
              > > > It's because 'confirm' only works for ":" commands. Not a very
              > > > good reason...
              > > >
              > > >
              > > > > The ":e #" command does follow the "set confirm" as expected.
              > > > >
              > > > > It would be convenient if CTRL-^ also followed the
              > > > > 'set confirm' setting, no ?
              > > >
              > > >
              > > > Try the patch below. The problem might be that the dialog pops up
              > > > too often then. This needs to be tested.
              > >
              > > Yes, this patch fixes it for CTRL-^.
              > >
              > > Now, I noticed that ":bn" command ignores the 'set confirm'.
              > >
              > > While ":n" command does follow the "set confirm".
              > >
              > > It would be convenient if "set confirm" also worked for ":bn".
              > >
              > >
              > > Jacob Lerner
              >
              > I would guess that the reason is that :bn never "abandons" a buffer,
              > but just walks around the buffer list, so that no confirm is needed
              > -- the previous buffer always stays loaded, only not visible, or at
              > least not in that particular window. :next, OTOH, will fail if the
              > current buffer cannot be "abandon"ed, thus if the buffer is modified
              > it will trigger the "confirm" mechanism if enabled. See
              >
              > :help :bnext
              > :help :next
              > :help abandon
              >
              > Regards,
              > Tony.

              My big mouth... I should have not only read the help, but followed the
              links, before answering. :help buffer-! shows I was wrong.

              Regards,
              Tony.
            • Bram Moolenaar
              ... This requires another patch. Again, please check if this doesn t cause the dialog to pop up too often. ... *************** *** 963,971 **** if (!forceit
              Message 6 of 10 , Sep 3, 2003
              • 0 Attachment
                Yakov Lerner wrote:

                > >>Why 'set confirm' is ignored by CTRL-^ command ?
                > >>Is it on purpose ?
                > >
                > > It's because 'confirm' only works for ":" commands. Not a very good
                > > reason...
                > >
                > >
                > >>The ":e #" command does follow the "set confirm" as expected.
                > >>
                > >>It would be convenient if CTRL-^ also followed the
                > >>'set confirm' setting, no ?
                > >
                > >
                > > Try the patch below. The problem might be that the dialog pops up too
                > > often then. This needs to be tested.
                >
                > Yes, this patch fixes it for CTRL-^.
                >
                > Now, I noticed that ":bn" command ignores the 'set confirm'.
                >
                > While ":n" command does follow the "set confirm".
                >
                > It would be convenient if "set confirm" also worked for ":bn".

                This requires another patch. Again, please check if this doesn't cause
                the dialog to pop up too often.

                *** ../vim-6.2.072/src/buffer.c Sun Aug 3 12:24:50 2003
                --- src/buffer.c Wed Sep 3 21:04:11 2003
                ***************
                *** 963,971 ****

                if (!forceit && bufIsChanged(buf))
                {
                ! EMSGN(_("E89: No write since last change for buffer %ld (add ! to override)"),
                ! buf->b_fnum);
                ! return FAIL;
                }

                /*
                --- 963,986 ----

                if (!forceit && bufIsChanged(buf))
                {
                ! #if defined(FEAT_GUI_DIALOG) || defined(FEAT_CON_DIALOG)
                ! if ((p_confirm || cmdmod.confirm) && p_write)
                ! {
                ! dialog_changed(buf, FALSE);
                ! # ifdef FEAT_AUTOCMD
                ! if (!buf_valid(buf))
                ! /* Autocommand deleted buffer, oops! It's not changed
                ! * now. */
                ! return FAIL;
                ! # endif
                ! }
                ! if (bufIsChanged(buf))
                ! #endif
                ! {
                ! EMSGN(_("E89: No write since last change for buffer %ld (add ! to override)"),
                ! buf->b_fnum);
                ! return FAIL;
                ! }
                }

                /*
              • Yakov Lerner
                ... No, this patch didn t change behavior of ;bn when set confirm is on. I m still getting E37: No write since last change (add ! to override) Debugger
                Message 7 of 10 , Sep 4, 2003
                • 0 Attachment
                  Bram Moolenaar wrote:


                  > Yakov Lerner wrote:
                  >>Now, I noticed that ":bn" command ignores the 'set confirm'.
                  >>While ":n" command does follow the "set confirm".
                  >>It would be convenient if "set confirm" also worked for ":bn".
                  > This requires another patch. Again, please check if this doesn't cause
                  > the dialog to pop up too often.
                  >
                  > *** ../vim-6.2.072/src/buffer.c Sun Aug 3 12:24:50 2003
                  > --- src/buffer.c Wed Sep 3 21:04:11 2003
                  > ***************
                  > *** 963,971 ****
                  >
                  > if (!forceit && bufIsChanged(buf))
                  > {
                  > ! EMSGN(_("E89: No write since last change for buffer %ld (add ! to override)"),
                  > ! buf->b_fnum);
                  > ! return FAIL;
                  > }
                  >
                  > /*
                  > --- 963,986 ----
                  >
                  > if (!forceit && bufIsChanged(buf))
                  > {
                  > ! #if defined(FEAT_GUI_DIALOG) || defined(FEAT_CON_DIALOG)
                  > ! if ((p_confirm || cmdmod.confirm) && p_write)
                  > ! {
                  > ! dialog_changed(buf, FALSE);
                  > ! # ifdef FEAT_AUTOCMD
                  > ! if (!buf_valid(buf))
                  > ! /* Autocommand deleted buffer, oops! It's not changed
                  > ! * now. */
                  > ! return FAIL;
                  > ! # endif
                  > ! }
                  > ! if (bufIsChanged(buf))
                  > ! #endif
                  > ! {
                  > ! EMSGN(_("E89: No write since last change for buffer %ld (add ! to override)"),
                  > ! buf->b_fnum);
                  > ! return FAIL;
                  > ! }
                  > }
                  >
                  > /*
                  >

                  No, this patch didn't change behavior of ";bn"
                  when "set confirm" is on. I'm still getting
                  E37: No write since last change (add ! to override)

                  Debugger showed that ":bn" skipped this whole 'if' (lines 954-1154):

                  [buffer.c]
                  951 /*
                  952 * delete buffer buf from memory and/or the list
                  953 */
                  954 if (unload)
                  955 {
                  ...
                  1154 }

                  , and 'unload' is 0. Debugger shows that ":bn" indeed didn't enter
                  the patched area. The E37 error message came from line 1180:

                  1178 if (action == DOBUF_GOTO && !can_abandon(curbuf, forceit))
                  1179 {
                  1180 EMSG(_(e_nowrtmsg));
                  1181 return FAIL;
                  1182 }


                  Yakov
                • Bram Moolenaar
                  ... [...] ... [...] ... Right, sorry. Additional patch: ... *************** *** 1162,1169 **** */ if (action == DOBUF_GOTO && !can_abandon(curbuf, forceit)) {
                  Message 8 of 10 , Sep 4, 2003
                  • 0 Attachment
                    Yakov Lerner wrote:

                    > >>Now, I noticed that ":bn" command ignores the 'set confirm'.
                    > >>While ":n" command does follow the "set confirm".
                    > >>It would be convenient if "set confirm" also worked for ":bn".
                    > > This requires another patch. Again, please check if this doesn't cause
                    > > the dialog to pop up too often.

                    [...]
                    >
                    > No, this patch didn't change behavior of ";bn"
                    > when "set confirm" is on. I'm still getting
                    > E37: No write since last change (add ! to override)
                    >
                    [...]
                    >
                    > , and 'unload' is 0. Debugger shows that ":bn" indeed didn't enter
                    > the patched area. The E37 error message came from line 1180:

                    Right, sorry. Additional patch:

                    *** ../vim-6.2.072/src/buffer.c Sun Aug 3 12:24:50 2003
                    --- src/buffer.c Thu Sep 4 20:32:07 2003
                    ***************
                    *** 1162,1169 ****
                    */
                    if (action == DOBUF_GOTO && !can_abandon(curbuf, forceit))
                    {
                    ! EMSG(_(e_nowrtmsg));
                    ! return FAIL;
                    }

                    /* Go to the other buffer. */
                    --- 1177,1198 ----
                    */
                    if (action == DOBUF_GOTO && !can_abandon(curbuf, forceit))
                    {
                    ! #if defined(FEAT_GUI_DIALOG) || defined(FEAT_CON_DIALOG)
                    ! if ((p_confirm || cmdmod.confirm) && p_write)
                    ! {
                    ! dialog_changed(curbuf, FALSE);
                    ! # ifdef FEAT_AUTOCMD
                    ! if (!buf_valid(buf))
                    ! /* Autocommand deleted buffer, oops! */
                    ! return FAIL;
                    ! # endif
                    ! }
                    ! if (bufIsChanged(curbuf))
                    ! #endif
                    ! {
                    ! EMSG(_(e_nowrtmsg));
                    ! return FAIL;
                    ! }
                    }

                    /* Go to the other buffer. */

                    --
                    Have you heard about the new Barbie doll? It's called Divorce
                    Barbie. It comes with all of Ken's stuff.

                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                    \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                    \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
                  • Yakov Lerner
                    ... [...] Thanks, this patch works. BTW What do you mean when you say dialog to pop up [not] too often ? Do you imply by not too often that user may still
                    Message 9 of 10 , Sep 5, 2003
                    • 0 Attachment
                      Bram Moolenaar wrote:
                      > Yakov Lerner wrote:
                      >
                      >
                      >>>>Now, I noticed that ":bn" command ignores the 'set confirm'.
                      >>>>While ":n" command does follow the "set confirm".
                      >>>>It would be convenient if "set confirm" also worked for ":bn".
                      >>>
                      >>>This requires another patch. Again, please check if this doesn't cause
                      >>>the dialog to pop up too often.
                      >>
                      >
                      > [...]
                      >
                      >>No, this patch didn't change behavior of ";bn"
                      >
                      >
                      > Right, sorry. Additional patch:
                      [...]

                      Thanks, this patch works.

                      BTW What do you mean when you say "dialog to pop up [not] too often" ?

                      Do you imply by "not too often" that user may still get
                      "Enn: No write ... (use !)" message with 'set confim' ?

                      Or do you imply that dialog, say, shall not falsely pop up when,
                      say, buffer wasn't modified ? What's "not too often" ?

                      --
                      Jacob Lerner
                    • Bram Moolenaar
                      ... It is very annoying when a dialog pops up when you don t want it. Since the place where the code was changed is rather generic, it is difficult to be sure
                      Message 10 of 10 , Sep 5, 2003
                      • 0 Attachment
                        Yakov Lerner wrote:

                        > >>>>Now, I noticed that ":bn" command ignores the 'set confirm'.
                        > >>>>While ":n" command does follow the "set confirm".
                        > >>>>It would be convenient if "set confirm" also worked for ":bn".
                        > >>>
                        > >>>This requires another patch. Again, please check if this doesn't cause
                        > >>>the dialog to pop up too often.
                        > >>
                        > >
                        > > [...]
                        > >
                        > >>No, this patch didn't change behavior of ";bn"
                        > >
                        > >
                        > > Right, sorry. Additional patch:
                        > [...]
                        >
                        > Thanks, this patch works.
                        >
                        > BTW What do you mean when you say "dialog to pop up [not] too often" ?
                        >
                        > Do you imply by "not too often" that user may still get
                        > "Enn: No write ... (use !)" message with 'set confim' ?
                        >
                        > Or do you imply that dialog, say, shall not falsely pop up when,
                        > say, buffer wasn't modified ? What's "not too often" ?

                        It is very annoying when a dialog pops up when you don't want it. Since
                        the place where the code was changed is rather generic, it is difficult
                        to be sure there is no situation where the dialog pops up when an error
                        message should have been generated.

                        So, after adding the patches, please use Vim and find out if nothing
                        undesired happens.

                        --
                        The question is: What do you do with your life?
                        The wrong answer is: Become the richest guy in the graveyard.
                        (billionaire and Oracle founder Larry Ellison)

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                        \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
                      Your message has been successfully submitted and would be delivered to recipients shortly.