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

nested autocommand question

Expand Messages
  • Hari Krishna Dara
    I am having trouble getting the [nested] flag working. Here is a simple ... function! FCRO() call input( FCRO: . expand( )) !chmod +w % checktime e!
    Message 1 of 8 , Feb 20, 2003
    View Source
    • 0 Attachment
      I am having trouble getting the [nested] flag working. Here is a simple
      code that demonstrates the problem:

      >>>>
      function! FCRO()
      call input("FCRO: " . expand('<afile>'))
      !chmod +w %
      checktime
      "e!
      endfunction

      function! FCShell()
      call input("FCShell: " . expand('<afile>'))
      "doautocmd BufReadPre
      e!
      "doautocmd BufRead
      endfunction

      function! BR()
      call input("BR: " . expand('<afile>'))
      endfunction

      au FileChangedRO * nested :call FCRO()
      au FileChangedShell * nested :call FCShell()
      au BufRead * :call BR()
      <<<<

      Start vim using '-u NONE' to avoid side effects and source the above
      scriptlet.

      1) When a file is modified externally, the FCShell() function gets
      called, which then reloads the file. The e! command doesn't
      generate BufReadPre and BufRead commands though the nested
      argument is specified while defining the autocommands, so I have
      to emulate this behavior by using doautocmd (commented above).

      2) When I start modifying a read-only file, the FCRO() function gets
      called, which executes an external command that modifies the file
      mode. But checktime doesn't detect this, so I have to force a
      reload by using :e! (commented above). This fires the BufRead
      autocommand (and probably BufReadPre also) (which didn't get fired
      when I removed nested flag, but still), I want to get the
      FileChangedShell fired in this case, but it doesn't happen.

      Am I doing anything wrong here or is it a vim bug? I am especially
      skeptical of needing to emulate the vim's default behavior in FCShell()
      above, as I can easily miss doing somethings that Vim would normally do.
      I would appreciate any help.

      Thank you,
      Hari
    • Benji Fisher
      ... [snip] ... [snip] I think you can make the example simpler: ==== function! BR() call input( BR: . expand( )) endfunction au FileChangedRO *
      Message 2 of 8 , Feb 21, 2003
      View Source
      • 0 Attachment
        Hari Krishna Dara wrote:
        > I am having trouble getting the [nested] flag working. Here is a simple
        > code that demonstrates the problem:
        [snip]
        > 1) When a file is modified externally, the FCShell() function gets
        > called, which then reloads the file. The e! command doesn't
        > generate BufReadPre and BufRead commands though the nested
        > argument is specified while defining the autocommands, so I have
        > to emulate this behavior by using doautocmd (commented above).
        >
        > 2) When I start modifying a read-only file, the FCRO() function gets
        > called, which executes an external command that modifies the file
        > mode. But checktime doesn't detect this, so I have to force a
        > reload by using :e! (commented above). This fires the BufRead
        > autocommand (and probably BufReadPre also) (which didn't get fired
        > when I removed nested flag, but still), I want to get the
        > FileChangedShell fired in this case, but it doesn't happen.
        >
        > Am I doing anything wrong here or is it a vim bug? I am especially
        > skeptical of needing to emulate the vim's default behavior in FCShell()
        > above, as I can easily miss doing somethings that Vim would normally do.
        > I would appreciate any help.
        >
        > Thank you,
        > Hari
        >

        [snip]

        I think you can make the example simpler:

        ====
        function! BR()
        call input("BR: " . expand('<afile>'))
        endfunction

        au FileChangedRO * nested !chmod +w %
        au FileChangedShell * nested e!
        au BufRead * call BR()
        ====

        Then ":e!" triggers the BR() function, but ":!touch %" does not (although it
        does reload the buffer).

        Let's look at the docs:


        *FileChangedShell*
        NOTE: This event never nests, to avoid an
        endless loop.

        I understand that as you probably did: the FileChangedShell event is never
        triggered by another autocommand. A little experimentation shows that it is the
        other way around. The FileChangedShell *can* be triggered by another
        autocommand (such as "au User foo nested !touch %") but it ignores the "nested"
        flag.

        For the second problem, I am not sure what is going on. When I add a new
        line with "o", it seems to trigger FileChangedRO, but FileChangedShell is not
        triggered until I leave Insert mode. If I delete a word, both are called, but
        the change is not made. According to the docs, the :e! should be executed (as
        part of the FileChangedRO event) before the change is made...

        Conclusions:

        1. The non-nesting of FileChangedShell should either be changed or better
        documented. If it is supposed to work the way it does now, I would like an
        error message when I try to do "au FileChangedShell * nested ..."

        2. The FileChangedRO event does not seem to be working properly.

        3. It should be easier to emulate the regular behavior when defining a
        FileChangedShell sutocommand.

        HTH --Benji Fisher
      • Bram Moolenaar
        ... I can understand that in FileChangedShell autocommands you would like to reload the file and expect autocommands to work as usual. Prevention from an
        Message 3 of 8 , Feb 22, 2003
        View Source
        • 0 Attachment
          Benji Fisher wrote:

          > Let's look at the docs:
          >
          >
          > *FileChangedShell*
          > NOTE: This event never nests, to avoid an
          > endless loop.
          >
          > I understand that as you probably did: the FileChangedShell event is never
          > triggered by another autocommand. A little experimentation shows that
          > it is the other way around. The FileChangedShell *can* be triggered
          > by another autocommand (such as "au User foo nested !touch %") but it
          > ignores the "nested" flag.

          I can understand that in FileChangedShell autocommands you would like to
          reload the file and expect autocommands to work as usual. Prevention
          from an endless loop can be done by checking if a FileChangedShell event
          is already being handled. I'll implement that.

          > For the second problem, I am not sure what is going on. When I add a
          > new line with "o", it seems to trigger FileChangedRO, but
          > FileChangedShell is not triggered until I leave Insert mode. If I
          > delete a word, both are called, but the change is not made. According
          > to the docs, the :e! should be executed (as part of the FileChangedRO
          > event) before the change is made...

          The FileChangedRO event is triggered before the change is actually made,
          but FileChangedShell much later. Vim only checks if the file changed at
          a few occasions, inserting text is not one of them (would slow down
          editing too much). Blindly doing ":e!" on a FileChangedShell event is
          the trouble, you should not use that.

          > Conclusions:
          >
          > 1. The non-nesting of FileChangedShell should either be changed or better
          > documented. If it is supposed to work the way it does now, I would like an
          > error message when I try to do "au FileChangedShell * nested ..."

          I'll change how this works.

          > 2. The FileChangedRO event does not seem to be working properly.

          I don't see this problem.

          > 3. It should be easier to emulate the regular behavior when defining a
          > FileChangedShell sutocommand.

          By allowing autocommands to trigger that should be solved now.

          --
          DEAD PERSON: I don't want to go in the cart!
          CUSTOMER: Oh, don't be such a baby.
          MORTICIAN: I can't take him...
          DEAD PERSON: I feel fine!
          CUSTOMER: Oh, do us a favor...
          MORTICIAN: I can't.
          The Quest for the Holy Grail (Monty Python)

          /// 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 at Amazon -- http://ICCF.nl/click1.html ///
        • Bram Moolenaar
          ... The message from Benji explains this. I ll add a modification that makes the BufRead autocommand events triggered in this situation. ... The effect of
          Message 4 of 8 , Feb 22, 2003
          View Source
          • 0 Attachment
            Hari Krishna Dara wrote:

            > I am having trouble getting the [nested] flag working. Here is a simple
            > code that demonstrates the problem:
            >
            > >>>>
            > function! FCRO()
            > call input("FCRO: " . expand('<afile>'))
            > !chmod +w %
            > checktime
            > "e!
            > endfunction
            >
            > function! FCShell()
            > call input("FCShell: " . expand('<afile>'))
            > "doautocmd BufReadPre
            > e!
            > "doautocmd BufRead
            > endfunction
            >
            > function! BR()
            > call input("BR: " . expand('<afile>'))
            > endfunction
            >
            > au FileChangedRO * nested :call FCRO()
            > au FileChangedShell * nested :call FCShell()
            > au BufRead * :call BR()
            > <<<<
            >
            > Start vim using '-u NONE' to avoid side effects and source the above
            > scriptlet.
            >
            > 1) When a file is modified externally, the FCShell() function gets
            > called, which then reloads the file. The e! command doesn't
            > generate BufReadPre and BufRead commands though the nested
            > argument is specified while defining the autocommands, so I have
            > to emulate this behavior by using doautocmd (commented above).

            The message from Benji explains this. I'll add a modification that
            makes the BufRead autocommand events triggered in this situation.

            > 2) When I start modifying a read-only file, the FCRO() function gets
            > called, which executes an external command that modifies the file
            > mode. But checktime doesn't detect this, so I have to force a
            > reload by using :e! (commented above). This fires the BufRead
            > autocommand (and probably BufReadPre also) (which didn't get fired
            > when I removed nested flag, but still), I want to get the
            > FileChangedShell fired in this case, but it doesn't happen.

            The effect of ":checktime" is postponed until Vim is back in the main
            loop. You can probably use ":do FileChangedShell %" (I didn't try it).

            --
            [clop clop]
            MORTICIAN: Who's that then?
            CUSTOMER: I don't know.
            MORTICIAN: Must be a king.
            CUSTOMER: Why?
            MORTICIAN: He hasn't got shit all over him.
            The Quest for the Holy Grail (Monty Python)

            /// 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 at Amazon -- http://ICCF.nl/click1.html ///
          • Hari Krishna Dara
            ... That will be great. Till the patch comes out, I would like to emulate the behavior, so is the above mechanism of firing BufReadPre and BufRead autocommands
            Message 5 of 8 , Feb 25, 2003
            View Source
            • 0 Attachment
              On Sat, 22 Feb 2003 at 3:34pm, Bram Moolenaar wrote:

              >
              > Hari Krishna Dara wrote:
              >
              > > I am having trouble getting the [nested] flag working. Here is a simple
              > > code that demonstrates the problem:
              > >
              > > >>>>
              > > function! FCRO()
              > > call input("FCRO: " . expand('<afile>'))
              > > !chmod +w %
              > > checktime
              > > "e!
              > > endfunction
              > >
              > > function! FCShell()
              > > call input("FCShell: " . expand('<afile>'))
              > > "doautocmd BufReadPre
              > > e!
              > > "doautocmd BufRead
              > > endfunction
              > >
              > > function! BR()
              > > call input("BR: " . expand('<afile>'))
              > > endfunction
              > >
              > > au FileChangedRO * nested :call FCRO()
              > > au FileChangedShell * nested :call FCShell()
              > > au BufRead * :call BR()
              > > <<<<
              > >
              > > Start vim using '-u NONE' to avoid side effects and source the above
              > > scriptlet.
              > >
              > > 1) When a file is modified externally, the FCShell() function gets
              > > called, which then reloads the file. The e! command doesn't
              > > generate BufReadPre and BufRead commands though the nested
              > > argument is specified while defining the autocommands, so I have
              > > to emulate this behavior by using doautocmd (commented above).
              >
              > The message from Benji explains this. I'll add a modification that
              > makes the BufRead autocommand events triggered in this situation.

              That will be great. Till the patch comes out, I would like to emulate
              the behavior, so is the above mechanism of firing BufReadPre and BufRead
              autocommands closest to the default behavior?

              >
              > > 2) When I start modifying a read-only file, the FCRO() function gets
              > > called, which executes an external command that modifies the file
              > > mode. But checktime doesn't detect this, so I have to force a
              > > reload by using :e! (commented above). This fires the BufRead
              > > autocommand (and probably BufReadPre also) (which didn't get fired
              > > when I removed nested flag, but still), I want to get the
              > > FileChangedShell fired in this case, but it doesn't happen.
              >
              > The effect of ":checktime" is postponed until Vim is back in the main
              > loop. You can probably use ":do FileChangedShell %" (I didn't try it).

              I tried this and it does work. Thanks for the suggestion.

              I am not sure what your answer was for the third point in Benji's email.

              > > 3. It should be easier to emulate the regular behavior when defining a
              > > FileChangedShell sutocommand.
              >
              > By allowing autocommands to trigger that should be solved now.

              Are you going to add a new mechanism to do this? Most often, IMHO,
              users would like to do something in addition to the default mechanism
              (of prompting user etc.), so overriding the default mechanism is not
              what they want. Also, I am guessing that users would like to have the
              choice of doing it before or after the file is reloaded, so both
              FileChangedShellPre and FileChangedShell events will be expected.

              Thanks a lot,
              Hari
            • Bram Moolenaar
              ... Should be about right. The patch will be available very soon. Perhaps later today. ... This event happens at an unpredictable moment (e.g., when gaining
              Message 6 of 8 , Feb 26, 2003
              View Source
              • 0 Attachment
                Hari Krishna Dara wrote:

                > > The message from Benji explains this. I'll add a modification that
                > > makes the BufRead autocommand events triggered in this situation.
                >
                > That will be great. Till the patch comes out, I would like to emulate
                > the behavior, so is the above mechanism of firing BufReadPre and BufRead
                > autocommands closest to the default behavior?

                Should be about right.

                The patch will be available very soon. Perhaps later today.

                > > > 3. It should be easier to emulate the regular behavior when defining a
                > > > FileChangedShell sutocommand.
                > >
                > > By allowing autocommands to trigger that should be solved now.
                >
                > Are you going to add a new mechanism to do this? Most often, IMHO,
                > users would like to do something in addition to the default mechanism
                > (of prompting user etc.), so overriding the default mechanism is not
                > what they want. Also, I am guessing that users would like to have the
                > choice of doing it before or after the file is reloaded, so both
                > FileChangedShellPre and FileChangedShell events will be expected.

                This event happens at an unpredictable moment (e.g., when gaining
                focus). I am very careful and want to discourage people to do something
                here. Adding more events gives a wrong idea.

                The above solution to trigger autocommands when loading the buffer
                should be sufficient in most situations.

                --
                Arthur pulls Pin out. The MONK blesses the grenade as ...
                ARTHUR: (quietly) One, two, five ...
                GALAHAD: Three, sir!
                ARTHUR: Three.
                "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                /// 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 at Amazon -- http://ICCF.nl/click1.html ///
              • Hari Krishna Dara
                ... I just want to confirm this. So is the :doautocmd on FileChangedShell going to be the recommended apprach for this? Will you be documenting it? Also, are
                Message 7 of 8 , Feb 28, 2003
                View Source
                • 0 Attachment
                  On Wed, 26 Feb 2003 at 9:00pm, Bram Moolenaar wrote:

                  >
                  > > > > 3. It should be easier to emulate the regular behavior when defining a
                  > > > > FileChangedShell sutocommand.
                  > > >
                  > > > By allowing autocommands to trigger that should be solved now.
                  > >
                  > > Are you going to add a new mechanism to do this? Most often, IMHO,
                  > > users would like to do something in addition to the default mechanism
                  > > (of prompting user etc.), so overriding the default mechanism is not
                  > > what they want. Also, I am guessing that users would like to have the
                  > > choice of doing it before or after the file is reloaded, so both
                  > > FileChangedShellPre and FileChangedShell events will be expected.
                  >
                  > This event happens at an unpredictable moment (e.g., when gaining
                  > focus). I am very careful and want to discourage people to do something
                  > here. Adding more events gives a wrong idea.
                  >
                  > The above solution to trigger autocommands when loading the buffer
                  > should be sufficient in most situations.

                  I just want to confirm this. So is the :doautocmd on FileChangedShell
                  going to be the recommended apprach for this? Will you be documenting
                  it?

                  Also, are you going to add some flag to FileChangedShell autocommand
                  that allows the default mechanism to continue to work even with the
                  autocommand defined? If not, I am going to keep the code that emulates
                  this behavior. If yes, I will have to throw it away (or make it
                  conditional to the version of Vim).

                  Thank you,
                  Hari
                • Bram Moolenaar
                  ... Well, this is quite specific. I don t really know where to add this remark in such a way that someone who needs it would actually find it. ... I have no
                  Message 8 of 8 , Mar 1, 2003
                  View Source
                  • 0 Attachment
                    Hari Krishna Dara wrote:

                    > > This event happens at an unpredictable moment (e.g., when gaining
                    > > focus). I am very careful and want to discourage people to do something
                    > > here. Adding more events gives a wrong idea.
                    > >
                    > > The above solution to trigger autocommands when loading the buffer
                    > > should be sufficient in most situations.
                    >
                    > I just want to confirm this. So is the :doautocmd on FileChangedShell
                    > going to be the recommended apprach for this? Will you be documenting
                    > it?

                    Well, this is quite specific. I don't really know where to add this
                    remark in such a way that someone who needs it would actually find it.

                    > Also, are you going to add some flag to FileChangedShell autocommand
                    > that allows the default mechanism to continue to work even with the
                    > autocommand defined? If not, I am going to keep the code that emulates
                    > this behavior. If yes, I will have to throw it away (or make it
                    > conditional to the version of Vim).

                    I have no plans to change this. Only when there is a very good reason I
                    would extend something in this area. It seems it's getting more
                    complicated every time something is added.

                    --
                    Living on Earth includes an annual free trip around the Sun.

                    /// 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 at Amazon -- http://ICCF.nl/click1.html ///
                  Your message has been successfully submitted and would be delivered to recipients shortly.