On Thu, Jul 25, 2013 at 12:53 AM, Bram Moolenaar <[email protected]> wrote:
> > Yukihiro Nakadaira wrote: > > > On Mon, Jul 8, 2013 at 9:51 AM, <[email protected]> wrote: > > > > > Bram Moolenaar wrote: > > > > > > > Announcing: Vim (Vi IMproved) version 7.4a BETA > > > > > > > > This is the first BETA release of Vim 7.4. > > > > > > > > Please check that the distribution is OK. I haven't done one for a > long > > > > time. Report anything that isn't right. That includes a crash but > also > > > > a typo in the documentation or a missing file. > > > > > > mid-2010 macbookpro > > > macosx-10.6.8 > > > gcc-4.2.1 > > > > > > obtained vim-7.4a.002 via hg (same result via ftp). > > > > > > configure \ > > > --disable-darwin \ > > > --with-x \ > > > --enable-gui=motif \ > > > --enable-multibyte \ > > > --with-mac-arch=current \ > > > --with-features=huge \ > > > --disable-acl > > > > > > Test results: > > > test96 FAILED > > > TEST FAILURE > > > > > > diff -u test96.ok test96.failed > > > --- test96.ok 2013-07-08 10:12:36.000000000 +1000 > > > +++ test96.failed 2013-07-08 10:15:31.000000000 +1000 > > > @@ -4,6 +4,8 @@ > > > - quickfix claims that the file name displayed is: test://bar.txt > > > Test B: > > > - number of window open: 2 > > > +Test B: > > > + - number of window open: 2 > > > Test C: > > > - 'buftype' of the location list window: quickfix > > > - buffer displayed in the 2nd window: test://quux.txt > > > > > > i.e. the "Test B" section of the file is repeated. > > > > > > > test96 failed on Windows Vista, too. > > > > Maybe I found the cause of this problem. test96 depends on cursor > > position after switching buffer. But it is not stable. Try the > > following script: > > > > call setline(1, range(10)) > > for i in range(5) > > new > > buffer 1 > > let &l:foldminlines = i > > call cursor(i, 1) > > endfor > > for i in range(5) > > quit > > endfor > > for i in range(5) > > new > > buffer 1 > > endfor > > > > Now, each window have different cursor position and different > > window-local option value (&l:foldminlines in this case). > > > > I guess: > > win_free() doesn't clear buf->b_wininfo. > > After freeing memory, win_alloc() can return same address. > > Then, buf->b_wininfo is re-used for newly allocated window in spite of > > diffrent window. > > It would be possible. Unfortunately I could not reproduce the problem. > > Please check if patch 7.4a.044 fixes the problem. The problem seems to be solved. Thank you. -- Yukihiro Nakadaira - [email protected] -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
