Re: vim7: E788 is too restrictive
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
Re: vim7: E788 is too restrictive
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 -- [EMAIL PROTECTED] -- 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///
Re: vim7: E788 is too restrictive
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
Re: vim7: E788 is too restrictive
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 -- [EMAIL PROTECTED] -- 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///
Re: vim7: E788 is too restrictive
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
vim7: E788 is too restrictive
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. 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). -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: vim7: E788 is too restrictive
Today (Wed, 31 May 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 get this error as well. There really needs to be some kind of compromise--I'm only forcing a reload of the current buffer when I'm trying to modify a readonly RCS controlled file. The documentation claims this is allowed but Vim7 trips all over itself. - Christian -- You get a democracy when three wolves and a sheep vote on what to have for dinner. Christian J. Robinson [EMAIL PROTECTED] http://infynity.spodzone.com/ PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp
Re: vim7: E788 is too restrictive
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 -- Never hold a dustbuster and a cat at the same time. Christian J. Robinson [EMAIL PROTECTED] http://infynity.spodzone.com/ PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp
