Re: BUG that will cause loss of edited text
Hi, On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote: Hi Bram and maintainers, I encountered this bug when editing files: 1) Open a file, change something. The file is marked as modifed. 2) Use Ctrl-W,Ctrl-] to go to the definition of any symbol in a new window. The newly opened file is unmodified, and the old one is still modified. 3) Use Ctrl-T or Ctrl-O to return to the old file (in the new window). At this point the upper window and the lower window display the same old file as in last saved state, reloaded, unmodified! Luckily when I encountered this I lost only about 10 minutes' work. I am not able to reproduce this problem. Did you try reproducing this problem by starting Vim with the command-line 'vim -N -u NONE -U NONE --noplugin'? - Yegappan
Re: BUG that will cause loss of edited text
Hi Yegappan, On 10/26/06, Yegappan Lakshmanan [EMAIL PROTECTED] wrote: Hi, On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote: Hi Bram and maintainers, I encountered this bug when editing files: 1) Open a file, change something. The file is marked as modifed. 2) Use Ctrl-W,Ctrl-] to go to the definition of any symbol in a new window. The newly opened file is unmodified, and the old one is still modified. 3) Use Ctrl-T or Ctrl-O to return to the old file (in the new window). At this point the upper window and the lower window display the same old file as in last saved state, reloaded, unmodified! Luckily when I encountered this I lost only about 10 minutes' work. I am not able to reproduce this problem. Did you try reproducing this problem by starting Vim with the command-line 'vim -N -u NONE -U NONE --noplugin'? Sorry I did not test this way earlier. No, I cannot reproduce this problem either now. So it is a plugin problem. I will check myself. Thanks. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: BUG that will cause loss of edited text
Hi list, On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote: Hi Yegappan, On 10/26/06, Yegappan Lakshmanan [EMAIL PROTECTED] wrote: Hi, On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote: Hi Bram and maintainers, I encountered this bug when editing files: 1) Open a file, change something. The file is marked as modifed. 2) Use Ctrl-W,Ctrl-] to go to the definition of any symbol in a new window. The newly opened file is unmodified, and the old one is still modified. 3) Use Ctrl-T or Ctrl-O to return to the old file (in the new window). At this point the upper window and the lower window display the same old file as in last saved state, reloaded, unmodified! Luckily when I encountered this I lost only about 10 minutes' work. I am not able to reproduce this problem. Did you try reproducing this problem by starting Vim with the command-line 'vim -N -u NONE -U NONE --noplugin'? Sorry I did not test this way earlier. No, I cannot reproduce this problem either now. So it is a plugin problem. I will check myself. Sorry for bugging the list again. It turns out to be a side-effect of an autocommand BufWinEnter in my _vimrc. What I want to do is some check after modeline is processed, but before editing begins. I did not check the latter part, and BufWinEnter is executed when display an already visible buffer in another window, apart from when processing the modelines after loading a new buffer. Any reliable way to check whether editing really begins (modified is not one)? Or an autocommand that is executed only after processing the modeline? Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: BUG that will cause loss of edited text
Yongwei Wu wrote: Hi list, On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote: Hi Yegappan, On 10/26/06, Yegappan Lakshmanan [EMAIL PROTECTED] wrote: Hi, On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote: Hi Bram and maintainers, I encountered this bug when editing files: 1) Open a file, change something. The file is marked as modifed. 2) Use Ctrl-W,Ctrl-] to go to the definition of any symbol in a new window. The newly opened file is unmodified, and the old one is still modified. 3) Use Ctrl-T or Ctrl-O to return to the old file (in the new window). At this point the upper window and the lower window display the same old file as in last saved state, reloaded, unmodified! Luckily when I encountered this I lost only about 10 minutes' work. I am not able to reproduce this problem. Did you try reproducing this problem by starting Vim with the command-line 'vim -N -u NONE -U NONE --noplugin'? Sorry I did not test this way earlier. No, I cannot reproduce this problem either now. So it is a plugin problem. I will check myself. Sorry for bugging the list again. It turns out to be a side-effect of an autocommand BufWinEnter in my _vimrc. What I want to do is some check after modeline is processed, but before editing begins. I did not check the latter part, and BufWinEnter is executed when display an already visible buffer in another window, apart from when processing the modelines after loading a new buffer. Any reliable way to check whether editing really begins (modified is not one)? Or an autocommand that is executed only after processing the modeline? Best regards, Yongwei To check if 'modified' is on or off, use if modified ... 'modified' is on ... else ... 'modified' is off ... endif For an autocommand, you can also use :au BufWinEnter foobar.baz if mod | call DoSomething() | else | \ call DoSomethingElse() | endif Or for something fancier: :au BufReadPost foobar.baz let b:firstload = 1 :au BufWinEnter foobar.baz nested if b:firstload | doautocmd User | \ let b:firstload = 0 | endif then the User event will be triggered once, after processing the modelines. If you can afford to do your preprocessing _before_ processing the modelines, then you can use the BufReadPost event. Best regards, Tony.
