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

Re: vim7: E788 is too restrictive

Expand Messages
  • Hari Krishna Dara
    ... Thanks for pointing this out... even perforce supports some keywords, so reloading is essential for me as well. -- Thanks, Hari
    Message 1 of 9 , Jun 1, 2006
      On Wed, 31 May 2006 at 11:47pm, Christian J. Robinson wrote:

      > Today (Wed, 31 May 2006), Hari Krishna Dara wrote:
      >
      > > The handling of FileChangedRO was never smooth for me. As a
      > > workaround, I am thinking of avoiding a reload altogether and just
      > > mark the buffer as 'noro'. I relied upon the reload for its side
      > > effects before, but I should be able to force them directly, so all
      > > I can think of that needs to be done after a successful checkout is
      > > to mark the buffer as non-readonly. Any comments?
      >
      > My problem with that is that RCS's "co"/"ci" commands modify the file
      > on disk if you have some of the special $...$ tags within the file, so
      > a reload of the buffer is essentially mandatory.
      >
      > - Christian

      Thanks for pointing this out... even perforce supports some keywords, so
      reloading is essential for me as well.

      --
      Thanks,
      Hari

      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com
    • Bram Moolenaar
      ... It looks like there is no problem with allowing the :compiler command here. This means it can also be used in the command line window. I ll change that.
      Message 2 of 9 , Jun 18, 2006
        Hari Krishna Dara wrote:

        > It seems like I am getting E788 error too often, without much reason.
        > The latest is for the :compiler command that is being executed from a
        > ftplugin. I narrowed it down to the command itself, not the compiler
        > plugin, as adding a :finish at the start of the compiler plugin didn't
        > get rid off the error, but commenting the :compiler call itself did.
        >
        > The problem occurs because I am reloading the buffer during the
        > FileChangedRO event, and manually triggering the BufRead event, because
        > for some reason this doesn't get triggered. Actually BufRead event
        > didn't in prior version also, but I was able to workaround this by
        > manually triggering FileChangedShell (Bram's suggestion), but this no
        > longer works properly. If FileChangedShell is triggered from
        > FileChangedRO, the v:fcs_reason gets ignored, so my workaround is to
        > just reload the file, and manually fire BufRead event, which is what is
        > causing the E788 error in this case.

        It looks like there is no problem with allowing the ":compiler" command
        here. This means it can also be used in the command line window.
        I'll change that.

        > The previous time I got E788 was in my FileChangedShell handler. Prior
        > to 7.0, since there was no v:fcs_reason support, I had to jump to the
        > buffer for which the event got triggered and conditionally reload the
        > buffer, but now this is no longer allowed. The reason I think this is
        > too restrictive is that the doc suggests that FileChangedShell is
        > allowed to reload related buffers, if you know what you are doing, but
        > you can't reload buffer without first switching to it (and, to repeat,
        > this causes E788).

        Vim has to be very careful. There have been several problems and
        crashes caused by allowing too much in autocommands. I rather stay on
        the safe side.

        --
        I'm sure that I asked CBuilder to do a "full" install. Looks like I got
        a "fool" install, instead. Charles E Campbell, Jr, PhD


        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
      • Hari Krishna Dara
        ... Thank you. ... Does this mean, the documentation will be updated as well? As I said, the documentation on FileChangedShell suggests that the user can do
        Message 3 of 9 , Jun 19, 2006
          On Sun, 18 Jun 2006 at 11:26pm, Bram Moolenaar wrote:

          >
          > Hari Krishna Dara wrote:
          >
          > > It seems like I am getting E788 error too often, without much reason.
          > > The latest is for the :compiler command that is being executed from a
          > > ftplugin. I narrowed it down to the command itself, not the compiler
          > > plugin, as adding a :finish at the start of the compiler plugin didn't
          > > get rid off the error, but commenting the :compiler call itself did.
          > >
          > > The problem occurs because I am reloading the buffer during the
          > > FileChangedRO event, and manually triggering the BufRead event, because
          > > for some reason this doesn't get triggered. Actually BufRead event
          > > didn't in prior version also, but I was able to workaround this by
          > > manually triggering FileChangedShell (Bram's suggestion), but this no
          > > longer works properly. If FileChangedShell is triggered from
          > > FileChangedRO, the v:fcs_reason gets ignored, so my workaround is to
          > > just reload the file, and manually fire BufRead event, which is what is
          > > causing the E788 error in this case.
          >
          > It looks like there is no problem with allowing the ":compiler" command
          > here. This means it can also be used in the command line window.
          > I'll change that.

          Thank you.

          >
          > > The previous time I got E788 was in my FileChangedShell handler. Prior
          > > to 7.0, since there was no v:fcs_reason support, I had to jump to the
          > > buffer for which the event got triggered and conditionally reload the
          > > buffer, but now this is no longer allowed. The reason I think this is
          > > too restrictive is that the doc suggests that FileChangedShell is
          > > allowed to reload related buffers, if you know what you are doing, but
          > > you can't reload buffer without first switching to it (and, to repeat,
          > > this causes E788).
          >
          > Vim has to be very careful. There have been several problems and
          > crashes caused by allowing too much in autocommands. I rather stay on
          > the safe side.
          >

          Does this mean, the documentation will be updated as well? As I said,
          the documentation on FileChangedShell suggests that the user can do
          something that is no longer possible in Vim7. I am talking specifically
          about this:

          >>>>
          This is useful for reloading related buffers
          which are affected by a single command.
          <<<<

          This is not possible anymore (or am I missing something?).

          --
          Thanks,
          Hari

          __________________________________________________
          Do You Yahoo!?
          Tired of spam? Yahoo! Mail has the best spam protection around
          http://mail.yahoo.com
        • Bram Moolenaar
          ... This remark is indeed confusing. You can still reload all buffers that are changed, but only one by one. But you can only reload the current buffer.
          Message 4 of 9 , Jun 19, 2006
            Hari Krishna Dara wrote:

            > > > The previous time I got E788 was in my FileChangedShell handler. Prior
            > > > to 7.0, since there was no v:fcs_reason support, I had to jump to the
            > > > buffer for which the event got triggered and conditionally reload the
            > > > buffer, but now this is no longer allowed. The reason I think this is
            > > > too restrictive is that the doc suggests that FileChangedShell is
            > > > allowed to reload related buffers, if you know what you are doing, but
            > > > you can't reload buffer without first switching to it (and, to repeat,
            > > > this causes E788).
            > >
            > > Vim has to be very careful. There have been several problems and
            > > crashes caused by allowing too much in autocommands. I rather stay on
            > > the safe side.
            >
            > Does this mean, the documentation will be updated as well? As I said,
            > the documentation on FileChangedShell suggests that the user can do
            > something that is no longer possible in Vim7. I am talking specifically
            > about this:
            >
            > >>>>
            > This is useful for reloading related buffers
            > which are affected by a single command.
            > <<<<
            >
            > This is not possible anymore (or am I missing something?).

            This remark is indeed confusing. You can still reload all buffers that
            are changed, but only one by one. But you can only reload the current
            buffer. Hmm, if another buffer is changed there must be some way to
            reload it, since the changed buffer may differ from the current buffer.

            --
            There are 10 kinds of people: Those who understand binary and those who don't.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
          • Hari Krishna Dara
            ... Right. A reload() function that takes a buffer number or name will be useful. -- Thanks, Hari __________________________________________________ Do You
            Message 5 of 9 , Jun 19, 2006
              On Mon, 19 Jun 2006 at 9:48pm, Bram Moolenaar wrote:

              >
              > Hari Krishna Dara wrote:
              >
              > > > > The previous time I got E788 was in my FileChangedShell handler. Prior
              > > > > to 7.0, since there was no v:fcs_reason support, I had to jump to the
              > > > > buffer for which the event got triggered and conditionally reload the
              > > > > buffer, but now this is no longer allowed. The reason I think this is
              > > > > too restrictive is that the doc suggests that FileChangedShell is
              > > > > allowed to reload related buffers, if you know what you are doing, but
              > > > > you can't reload buffer without first switching to it (and, to repeat,
              > > > > this causes E788).
              > > >
              > > > Vim has to be very careful. There have been several problems and
              > > > crashes caused by allowing too much in autocommands. I rather stay on
              > > > the safe side.
              > >
              > > Does this mean, the documentation will be updated as well? As I said,
              > > the documentation on FileChangedShell suggests that the user can do
              > > something that is no longer possible in Vim7. I am talking specifically
              > > about this:
              > >
              > > >>>>
              > > This is useful for reloading related buffers
              > > which are affected by a single command.
              > > <<<<
              > >
              > > This is not possible anymore (or am I missing something?).
              >
              > This remark is indeed confusing. You can still reload all buffers that
              > are changed, but only one by one. But you can only reload the current
              > buffer. Hmm, if another buffer is changed there must be some way to
              > reload it, since the changed buffer may differ from the current buffer.

              Right. A reload() function that takes a buffer number or name will be
              useful.

              --
              Thanks,
              Hari

              __________________________________________________
              Do You Yahoo!?
              Tired of spam? Yahoo! Mail has the best spam protection around
              http://mail.yahoo.com
            Your message has been successfully submitted and would be delivered to recipients shortly.