On Sep 24, 6:03 pm, Wincent Colaiuta <[email protected]> wrote: > Hi, > > Originally posted to vim_use some time ago: > > http://groups.google.com/group/vim_use/browse_thread/thread/a122376e8... > > Posting again here as it seems a more appropriate forum for bug > reports. > > I'm the author of the Command-T plug-in, which is a Vim plugin partly > written in Ruby: > > https://wincent.com/products/command-t > > I've received multiple reports from people on different platforms that > there is breakage running under 7.3 on their platform (I'm afraid I > can't reproduce on Mac OS X though): > > https://wincent.com/issues/1617 > > The apparent cause is that, for them, evaluating "$curbuf.number" > under Ruby _always_ returns 0, when it is supposed to return a > positive integer buffer number. To test, just do this: > > :ruby puts $curbuf.number > > If you're on an affected platform/Vim, you'll always see 0 regardless > of which buffer is current. Otherwise you'll see some positive > integer. > > So two questions: > > - Is this a known bug in 7.3? > > - And if it's not a known issue, what information can I gather from > these users to help troubleshoot this? > > Cheers, > Wincent
Using hg bisect I found out that Vim changeset 2131 is causing this problem. It adds support for the --enable-largefile and --disable- largefile configure flags. Compiling the latest version of Vim using -- disable-largefile (the non-default option) fixes the problem. Unfortunately, I did not have enough time to figure out why --enable- largefile causes the problem. Best regards, Ton van den Heuvel -- 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
