Comments
-
Greg Hurrell
Thanks for the report. I haven't had a change to try the Vim 7.3 series yet, and only now I see that 7.3b was released a few days ago. Will check it out and see if I can reproduce the fault.
-
Greg Hurrell
Strange, I just cloned the Vim repo and did a clean build of 7.3b. Command-T still works for me fine; didn't even need to recompile it.
Did you have a working Command-T installation before installing 7.3b?
Did you try re-installing the Command-T vimball again and recompiling it? (To be honest, I doubt this will help seeing as I don't think you would even have gotten as far as
CommandTAcceptSelectionif it wasn't installed and compiled. But it might be worth a try.)Are there any specific steps that you can post to reproduce the problem? (ie. opening in a split or whatever)
-
anonymous
a typo,
hg clone https://vim.googlecode.com/hg/ vim73
thanks for your test
Yes I have a working Command-T even after installing 7.3b. But there are some updates on the 7.3b branch later.
Command-t doesn't work well after Jul 21 vim update, the same problem on my home and office pc.
I create a new user, recompiling vim and command-t 0.8b，the same result.
There are no specific steps.
my build configuration:
./configure --prefix=/usr --with-features=huge --disable-xsmp --disable-xsmp-interact --disable-selinux --enable-luainterp --enable-perlinterp --enable-pythoninterp --enable-rubyinterp --enable-cscope --enable-netbeans --enable-multibyte --enable-xim --disable-hangulinput --enable-gui=gtk2
-
Greg Hurrell
So you're seeing that error message as soon as you hit
<leader>t? Or only when you select a file and try to open it?Also, have you got anything special in your
~/.vimrcor systemvimrc? -
anonymous
select a file and try to open it
Also, have you got anything special in your ~/.vimrc or system vimrc?
no, I use the default vimrc_example ( rename it to .vimrc) and without any plugin.
select a file and try to open it, then it show me those error messages, and the command-t file chooser buffer doesn't disappear. After I close the file, choose another file from the command-t file chooser ( because it doesn't disappear, I have to do that) Then the command-t buffer was disappear.
I'll try it on my another linux system ( the third one) later
-
Greg Hurrell
Ok, let me know how you go. The version I tested with was just built using
CONF_OPT_RUBY=--enable-rubyinterp make, so I might try it later with more stuff turned on like in your build. -
anonymous
It seems that
@buffer.number and @initial_buffer always return "0"
controller.rb line 57
match_window.rb line 99
lusty-explorer, lusty-juggler also has the same problem.
I build the latest ruby, the same result.
-
anonymous
The same result on my another linux system (fedora 12, fresh install)
-
Greg Hurrell
Interesting. I've tested against 7.3 (latest Hg source from a few days ago) and also with the MacVim 7.3 beta from a couple of days ago and can't reproduce.
I am going to look into those places in the code that you reference and see if I can spot anything strange.
-
Greg Hurrell
So both of those places where you're getting
0, what happens when you do this?:ruby puts $curbuf.number
-
anonymous
:ruby puts $curbuf.numberalways return0, but$curbuf.namehas different valueNow I have a workaround, use
$curbuf.nameinstead of$curbuf.number. -
Greg Hurrell
Must admit that I find it very puzzling that
$curbuf.numberis always zero for you. It's definitely not supposed to be that way according to Vim's own Ruby docs, and I haven't ever seen it with any version of Ruby or Vim. The surprising thing is that you've seen it on 2 machines, with different versions of Ruby and Vim... bizarre... -
anonymous
I was also having this issue on Ubuntu 10.04 with Vim 7.3 using the default system Ruby (viz. apt-get install ruby ruby-dev) installed by following the instructions from http://www.vim.org/mercurial.php where $curbuf.number always returned 0 and can confirm that changing controller.rb and match_window.rb to use .name instead of .number when referring to the buffer seems to fix this issue.
-
anonymous
Have same problem after vim update to 7.3 on debian. Just tried to install clean vim and command-T script - get same error more and more again
-
Greg Hurrell
Sounds like a bug in Vim to me; it just doesn't make sense for
$curbuf.numberto always return zero. The bug may be specific to particular distros or platforms, as I don't see it here (on Mac OS X). The bug appears independently of whether Command-T is present or not.I'd rather see this fixed in upstream Vim rather than implementing this kind of workaround in Command-T itself (what happens if you end up having two buffers with the same
name? You'll end up with non-deterministic behavior). Has anyone reported this bug upstream on the Vim list? -
anonymous
I also have the issue.
$curbuf.numberalways return0to make the lusty-explorer.vim plugin error and sometimes even get a SIGSEGV signal. -
Greg Hurrell
anonymous, what platform are you on and what version of Vim you running? Have you reported the bug on the Vim list?
-
Greg Hurrell
Posted to the vim_use mailing list here to see if anyone has anything to add:
http://groups.google.com/group/vim_use/browse_thread/thread/a122376e8dbc6d29
-
anonymous
Hi Wincent Colaiuta, I'm the anonymous an hour ago. My OS is Ubuntu 10.04 and affected Vim version is 7.3 (include 7.3b and 7.3f, that's all 7.3 version I've tried). It seems that in source file
if_ruby.c, the global variablecurbufhas the memberb_fnumwith value0, while inif_python.cit has the correct value. -
Greg Hurrell
Summary changed:
- From: vim 7.3b breaks up with command-t
- To: $curbuf.number always returns 0 (zero) instead of actual buffer number on some platforms/Vim versions
-
Maciej Lotkowski
I faced this bug too. I eployed this workaround with name instead of number and it works fine, since I usually do not issue commands which can change buffer name.
Linux 2.6.35-ARCH, Vim 7.3.3
-
Maciej Lotkowski
Apparently this workaround doesn't work so well. Vim crashes from time to time while using CommandT (vim: Caught deadly signal ABRT). It seems that I have to downgrade.
-
Greg Hurrell
I suspect the crashes aren't related to the buffer number issue, nor your workaround, but are a completely separate issue (I've heard reports of Vim being unstable with Ruby 1.9; you using 1.9 by any chance?).
-
Maciej Lotkowski
I do. I'll try to upgrade and use 1.8.7.
-
Greg Hurrell
Definitely worth a try. I'm using 7.3 (MacVim) with Ruby 1.8.7 and it hasn't skipped a beat.
-
adam
Hi there,
I can confirm this bug on vim 7.3 with ruby 1.9 on Linux. I downgraded vim and all is fine for now. Since it seems like a bug in vim, have anyone reported it? I'd do it myself, but you guys can probably describe the problem better.
-
anonymous
Hi Wincent et al... I have the same issue with ruby 1.8.5 and vim 7.3. I built with ./configure --prefix=/home/me/apps/vim --enable-rubyinterp and :ruby puts $curbuf.number always returns 0.
Reading reports of 1.8.7 working fine, I built that to my ~/apps/ruby and rebuilt vim against it. I got the exact same result.
I'll keep an eye over here, so let me know if there's any more info I can share or things I could try. Hope this helps...
-Adam
-
Greg Hurrell
To sum things up...
Seems to be platform-dependent rather than specific to any particular version of Ruby, at least from what I can tell here:
- everyone who has seen the issue is using vim 7.3 (but not everyone using 7.3 has seen the issue)
- people using different versions of Ruby have seen the issue (1.8.5, 1.8.7, 1.9 reported so far)
- it looks to be a bug in Vim itself, although it is a mystery why it doesn't occur on all platforms (the closest we have to an in-depth analysis of the bug is this comment)
We have two workarounds that people affected by the problem can use:
- either use 7.2 until the bug is fixed in upstream; or
-
hack Command-T to use
$curbuf.namerather than$curbuf.number; this an approach that I am quite reluctant to include in any official release of Command-T because the buffer number is documented as being immutable and unique but the name is not (the reason why I am concerned about uniqueness is that Command-T has to get rid of the buffer in question using:bwipeout!, and obviously the consequences of disposing of the wrong buffer are nasty)
The issue was reported in this thread but nobody seemed to take notice of it. I don't know if there is some other more official channel that we're supposed to use to report Vim bugs, so I've reposted it to vim_dev (where it is currently held for moderation).
-
Ton van den Heuvel
Using
hg bisectI found out that Vim changeset 2131 is causing this problem. It adds support for the--enable-largefileand--disable-largefileconfigure flags. Compiling the latest version of Vim using--disable-largefile(the non-default option) fixes the problem. I did not have enough time to figure out why the default--enable-largefilecauses the problem unfortunately. -
anonymous
I've rebuild vim with the --disable-largefile option, now lusty-explorer[juggler] and command-t are all ok.
-
Greg Hurrell
Ah, wonderful. Thanks for doing that. I was going to update vim_dev thread with this info, but I see you've already done that.
-
anonymous
I can approve that this fixed the issue for me also (Ububutn and vim 7.3 compiled from source)
-
anonymous
Wincent, et al: Thanks!
-
anonymous
Confirmed as well that Ubuntu 10.10 w/ Vim 7.3 compiled with --disable-largefile worked.
-
Greg Hurrell
Here's the bisected commit (output of
hg log --patch --rev 2131:8ef9da918a98 | less):changeset: 2131:8ef9da918a98 user: Bram Moolenaar <bram@zimbu.org> date: Fri May 07 16:05:55 2010 +0200 summary: updated for version 7.2.413 diff -r 279380a812ad -r 8ef9da918a98 src/auto/configure --- a/src/auto/configure Fri May 07 15:52:08 2010 +0200 +++ b/src/auto/configure Fri May 07 16:05:55 2010 +0200 @@ -821,6 +821,7 @@ with_gnome with_motif_lib with_tlib +enable_largefile enable_acl enable_gpm enable_sysmouse @@ -1485,6 +1486,7 @@ --enable-nextaw-check If auto-select GUI, check for neXtaw default=yes --enable-carbon-check If auto-select GUI, check for Carbon default=yes --disable-gtktest Do not try to compile and run a test GTK program + --disable-largefile omit support for large files --disable-acl Don't check for ACL support. --disable-gpm Don't use gpm (Linux mouse daemon). --disable-sysmouse Don't use sysmouse (mouse in *BSD console). @@ -14345,6 +14347,363 @@ fi +# Check whether --enable-largefile was given. +if test "${enable_largefile+set}" = set; then + enableval=$enable_largefile; +fi + +if test "$enable_largefile" != no; then + + { $as_echo "$as_me:$LINENO: checking for special C compiler options needed for large files" >&5 +$as_echo_n "checking for special C compiler options needed for large files... " >&6; } +if test "${ac_cv_sys_largefile_CC+set}" = set; then + $as_echo_n "(cached) " >&6 +else + ac_cv_sys_largefile_CC=no + if test "$GCC" != yes; then + ac_save_CC=$CC + while :; do + # IRIX 6.2 and later do not support large files by default, + # so use the C compiler's -n32 option if that helps. + cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#include <sys/types.h> + /* Check that off_t can represent 2**63 - 1 correctly. + We can't simply define LARGE_OFF_T to be 9223372036854775807, + since some C++ compilers masquerading as C compilers + incorrectly reject 9223372036854775807. */ +#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) + int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 + && LARGE_OFF_T % 2147483647 == 1) + ? 1 : -1]; +int +main () +{ + + ; + return 0; +} +_ACEOF + rm -f conftest.$ac_objext +if { (ac_try="$ac_compile" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" +$as_echo "$ac_try_echo") >&5 + (eval "$ac_compile") 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && { + test -z "$ac_c_werror_flag" || + test ! -s conftest.err + } && test -s conftest.$ac_objext; then + break +else + $as_echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + +fi + +rm -f core conftest.err conftest.$ac_objext + CC="$CC -n32" + rm -f conftest.$ac_objext +if { (ac_try="$ac_compile" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" +$as_echo "$ac_try_echo") >&5 + (eval "$ac_compile") 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && { + test -z "$ac_c_werror_flag" || + test ! -s conftest.err + } && test -s conftest.$ac_objext; then + ac_cv_sys_largefile_CC=' -n32'; break +else + $as_echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + +fi + +rm -f core conftest.err conftest.$ac_objext + break + done + CC=$ac_save_CC + rm -f conftest.$ac_ext + fi +fi +{ $as_echo "$as_me:$LINENO: result: $ac_cv_sys_largefile_CC" >&5 +$as_echo "$ac_cv_sys_largefile_CC" >&6; } + if test "$ac_cv_sys_largefile_CC" != no; then + CC=$CC$ac_cv_sys_largefile_CC + fi + + { $as_echo "$as_me:$LINENO: checking for _FILE_OFFSET_BITS value needed for large files" >&5 +$as_echo_n "checking for _FILE_OFFSET_BITS value needed for large files... " >&6; } +if test "${ac_cv_sys_file_offset_bits+set}" = set; then + $as_echo_n "(cached) " >&6 +else + while :; do + cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#include <sys/types.h> + /* Check that off_t can represent 2**63 - 1 correctly. + We can't simply define LARGE_OFF_T to be 9223372036854775807, + since some C++ compilers masquerading as C compilers + incorrectly reject 9223372036854775807. */ +#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) + int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 + && LARGE_OFF_T % 2147483647 == 1) + ? 1 : -1]; +int +main () +{ + + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (ac_try="$ac_compile" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" +$as_echo "$ac_try_echo") >&5 + (eval "$ac_compile") 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && { + test -z "$ac_c_werror_flag" || + test ! -s conftest.err + } && test -s conftest.$ac_objext; then + ac_cv_sys_file_offset_bits=no; break +else + $as_echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + +fi + +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext + cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#define _FILE_OFFSET_BITS 64 +#include <sys/types.h> + /* Check that off_t can represent 2**63 - 1 correctly. + We can't simply define LARGE_OFF_T to be 9223372036854775807, + since some C++ compilers masquerading as C compilers + incorrectly reject 9223372036854775807. */ +#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) + int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 + && LARGE_OFF_T % 2147483647 == 1) + ? 1 : -1]; +int +main () +{ + + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (ac_try="$ac_compile" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" +$as_echo "$ac_try_echo") >&5 + (eval "$ac_compile") 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && { + test -z "$ac_c_werror_flag" || + test ! -s conftest.err + } && test -s conftest.$ac_objext; then + ac_cv_sys_file_offset_bits=64; break +else + $as_echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + +fi + +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext + ac_cv_sys_file_offset_bits=unknown + break +done +fi +{ $as_echo "$as_me:$LINENO: result: $ac_cv_sys_file_offset_bits" >&5 +$as_echo "$ac_cv_sys_file_offset_bits" >&6; } +case $ac_cv_sys_file_offset_bits in #( + no | unknown) ;; + *) +cat >>confdefs.h <<_ACEOF +#define _FILE_OFFSET_BITS $ac_cv_sys_file_offset_bits +_ACEOF +;; +esac +rm -rf conftest* + if test $ac_cv_sys_file_offset_bits = unknown; then + { $as_echo "$as_me:$LINENO: checking for _LARGE_FILES value needed for large files" >&5 +$as_echo_n "checking for _LARGE_FILES value needed for large files... " >&6; } +if test "${ac_cv_sys_large_files+set}" = set; then + $as_echo_n "(cached) " >&6 +else + while :; do + cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#include <sys/types.h> + /* Check that off_t can represent 2**63 - 1 correctly. + We can't simply define LARGE_OFF_T to be 9223372036854775807, + since some C++ compilers masquerading as C compilers + incorrectly reject 9223372036854775807. */ +#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) + int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 + && LARGE_OFF_T % 2147483647 == 1) + ? 1 : -1]; +int +main () +{ + + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (ac_try="$ac_compile" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" +$as_echo "$ac_try_echo") >&5 + (eval "$ac_compile") 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && { + test -z "$ac_c_werror_flag" || + test ! -s conftest.err + } && test -s conftest.$ac_objext; then + ac_cv_sys_large_files=no; break +else + $as_echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + +fi + +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext + cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#define _LARGE_FILES 1 +#include <sys/types.h> + /* Check that off_t can represent 2**63 - 1 correctly. + We can't simply define LARGE_OFF_T to be 9223372036854775807, + since some C++ compilers masquerading as C compilers + incorrectly reject 9223372036854775807. */ +#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) + int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 + && LARGE_OFF_T % 2147483647 == 1) + ? 1 : -1]; +int +main () +{ + + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (ac_try="$ac_compile" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" +$as_echo "$ac_try_echo") >&5 + (eval "$ac_compile") 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && { + test -z "$ac_c_werror_flag" || + test ! -s conftest.err + } && test -s conftest.$ac_objext; then + ac_cv_sys_large_files=1; break +else + $as_echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + +fi + +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext + ac_cv_sys_large_files=unknown + break +done +fi +{ $as_echo "$as_me:$LINENO: result: $ac_cv_sys_large_files" >&5 +$as_echo "$ac_cv_sys_large_files" >&6; } +case $ac_cv_sys_large_files in #( + no | unknown) ;; + *) +cat >>confdefs.h <<_ACEOF +#define _LARGE_FILES $ac_cv_sys_large_files +_ACEOF +;; +esac +rm -rf conftest* + fi +fi + + { $as_echo "$as_me:$LINENO: checking for st_blksize" >&5 $as_echo_n "checking for st_blksize... " >&6; } cat >conftest.$ac_ext <<_ACEOF diff -r 279380a812ad -r 8ef9da918a98 src/config.h.in --- a/src/config.h.in Fri May 07 15:52:08 2010 +0200 +++ b/src/config.h.in Fri May 07 16:05:55 2010 +0200 @@ -196,6 +196,11 @@ [/tags/undef #undef] HAVE_UTIME [/tags/undef #undef] HAVE_BIND_TEXTDOMAIN_CODESET +/* Define, if needed, for accessing large files. */ +#undef _LARGE_FILES +#undef _FILE_OFFSET_BITS +#undef _LARGEFILE_SOURCE + /* Define if you do not have utime(), but do have the utimes() function. */ [/tags/undef #undef] HAVE_UTIMES diff -r 279380a812ad -r 8ef9da918a98 src/configure.in --- a/src/configure.in Fri May 07 15:52:08 2010 +0200 +++ b/src/configure.in Fri May 07 16:05:55 2010 +0200 @@ -2669,6 +2669,10 @@ usleep utime utimes) AC_FUNC_FSEEKO +dnl define _LARGE_FILES, _FILE_OFFSET_BITS and _LARGEFILE_SOURCE when +dnl appropriate, so that off_t is 64 bits when needed. +AC_SYS_LARGEFILE + dnl fstatfs() can take 2 to 4 arguments, try to use st_blksize if possible AC_MSG_CHECKING(for st_blksize) AC_TRY_COMPILE( diff -r 279380a812ad -r 8ef9da918a98 src/version.c --- a/src/version.c Fri May 07 15:52:08 2010 +0200 +++ b/src/version.c Fri May 07 16:05:55 2010 +0200 @@ -682,6 +682,8 @@ static int included_patches[] = { /* Add new patch number below this line */ /**/ + 413, +/**/ 412, /**/ 411,Obviously, still some analysis required as to exactly why the large file support triggers this bug.
-
Greg Hurrell
While we are waiting for upstream to get fixed, here is the workaround patch I am working with:
commit fa3847004abdf5f87333043a3ea5296458e454b7 (HEAD, master) Author: Greg Hurrell <greg@hurrell.net> Date: Thu Nov 4 10:26:47 2010 +0100 Fall back to buffer name on platforms affected by buffer number bug I was reluctant to use the buffer name instead of the buffer number, but on platforms affected by the bug we have two choices: - allow the bug to break Command-T, causing support requests and requiring people to either patch the source or rebuild Vim - fall back to the buffer name, which may not be entirely robust but at least is better than being totally broken Seeing as we can maintain the correct, robust behavior on platforms not affected by the bug, and only use the fallback behavior when required, adding this workaround is probably acceptable until upstream Vim gets fixed. See: https://wincent.dev/issues/1617 Signed-off-by: Greg Hurrell <greg@hurrell.net> diff --git a/ruby/command-t/match_window.rb b/ruby/command-t/match_window.rb index da08fa4..b75b0d2 100644 --- a/ruby/command-t/match_window.rb +++ b/ruby/command-t/match_window.rb @@ -56,8 +56,8 @@ module CommandT # show match window split_location = options[:match_window_at_top] ? 'topleft' : 'botright' if @@buffer # still have buffer from last time - ::VIM::command "silent! #{split_location} #{@@buffer.number}sbuffer" - raise "Can't re-open GoToFile buffer" unless $curbuf.number == @@buffer.number + ::VIM::command "silent! #{split_location} sbuffer #{buffer_id @@buffer}" + raise "Can't re-open GoToFile buffer" unless buffer_id($curbuf) == buffer_id(@@buffer) $curwin.height = 1 else # creating match window for first time and set it up split_command = "silent! #{split_location} 1split GoToFile" @@ -105,7 +105,7 @@ module CommandT end def close - ::VIM::command "bunload! #{@@buffer.number}" + ::VIM::command "bunload! #{buffer_id @@buffer}" restore_window_dimensions @settings.restore @prompt.dispose @@ -199,6 +199,22 @@ module CommandT private + # Workaround for upstream bug in Vim 7.3 on some platforms + # + # On some platforms, $curbuf.number always returns 0. One workaround is + # to build Vim with --disable-largfile, but as this is producing lots of + # support requests, implement the following fallback to the buffer name + # instead, at least until upstream gets fixed. + # + # For more details, see: https://wincent.dev/issues/1617 + def buffer_id buffer + if $curbuf.number == 0 + buffer.number + else + buffer.name + end + end + def print_error msg return unless VIM::Window.select(@window) unlockIf somebody who is seeing the issue can try this out and confirm that it fixes the problem for them that would be great. (Note you might actually have to use the
HEADversion from git://git.wincent.dev/command-t.git seeing as this patch builds on top of other recent commits.)Unfortunately on my system I can't reproduce the original problem even when I compile with
--enable-largefile. I don't know if this is because I'm on a 64-bit machine (in which case "large file" is probably the same as "normal file"), or because I'm on Mac OS X. Either way, I can't test it, and it also makes it pretty much impossible for me to investigate the problem in upstream Vim (that, and my ignorance of the Vim codebase). -
Greg Hurrell
And here's a better fix.
-
anonymous
I just checked out the latest master of command-t and tried things out. When I open command-t, select a file and hit enter, the following error shows up:
Error detected while processing function CommandTAcceptSelection: line 1: Zero count: silent b 0
Then, the command-t file selection window closes (which is a lot better than in the old version I was using, where it just wouldn't close and I ended up killing vim). When using command-t a second time in a vim instance, only one error is shown:
Zero count: silent b 0
For now, I just recompiled vim with --disable-largefile. Nevertheless, thank you for your efforts, Wincent!
--Flo
-
Greg Hurrell
Ah, thanks for the report. There looks to be one place where buffer number is still used: line 57 in the
controller.rbfile. I'll have to add another check for the always-zero buffer number there too. -
Marius Gedminas
I, too, can confirm that command-t 0.8.1 produces two "Zero count" errors -- one for
bwipeout! 0, and one forsilent b 0, while git head produces only one. Thehidemethod in controller.rb also needs a workaround. This worked for me:--- ruby/command-t/controller.rb +++ ruby/command-t/controller.rb @@ -54,7 +54,19 @@ module CommandT def hide @match_window.close if VIM::Window.select @initial_window - ::VIM::command "silent b #{@initial_buffer.number}" + # Workaround for upstream bug in Vim 7.3 on some platforms + # + # On some platforms, $curbuf.number always returns 0. One workaround is + # to build Vim with --disable-largefile, but as this is producing lots of + # support requests, implement the following fallback to the buffer name + # instead, at least until upstream gets fixed. + # + # For more details, see: https://wincent.dev/issues/1617 + if @initial_buffer.number == 0 + ::VIM::command "silent b #{@initial_buffer.name}" + else + ::VIM::command "silent b #{@initial_buffer.number}" + end end endI don't know if there is some other more official channel that we're supposed to use to report Vim bugs
:help bugswill tell you to send an email to bugs@vim.org, or ask in vim-dev. -
Greg Hurrell
Thanks for the tip. I sent a message to bugs@vim.org with a summary of what we've found. Hopefully that will help.
Seeing as we have a workaround in Command-T itself now, and the issue has been reported upstream, I'm going to mark this ticket as closed, but feel free to add more comments if you have other remarks or observations to make.
-
Greg Hurrell
Status changed:
- From: new
- To: closed
-
anonymous
Let me try to help with some further information.
My wife and me both use an updated Debian unstable system. The problem happens in her computer, but doesn't happen on mine. The only difference I can see is that her distribution is based on x86 and mine is based on x86_64. I don't know if that happens, but maybe this bug only affects x86 systems...
Rodrigo Rosenfeld Rosas
-
tempire
As I understand from the last comment, a command-t pull from github should be working fine with vim73.
I'm having the same issue, however, with vim73 (just now pulled from the vim googlecode repo)
Am I missing something here?
-
Greg Hurrell
Yeah, the latest Command-T should work around the problem if you are on an affected platform. At the time of writing, the current HEAD in the Git repo is the same as the 1.0b release, so pulling via Git isn't strictly necessary; you could install the 1.0b Vimball if you prefer that.
May I ask how you installed it? However you installed it, can you check that the version you installed actually does contain the fix?
Specifically, the
match_window.rbfile should have these changes.If either of those files doesn't look like they do in the repo, something didn't get installed properly.
If those definitely are installed correctly, then I'll need to know more about exactly what the failure is that you're seeing.
And while I'm here, no news yet on an upstream fix in Vim. I did send a report in to bugs@vim.org, like I said, but I haven't had any response or seen anything on the vim_dev Google group about it.
-
anonymous
I was affected by this problem for a long time under vim, but now I can report that ruby (1.9.2-p180) and vim 7.3 with patches 1-125 I now get $curbuf.number reporting something other than zero. I'm on Arch linux, 32bit.
I thought I'd leave this comment in case you wanted to undo the workaround for newer versions of vim, perhaps you were already aware of this.
-
Greg Hurrell
Thanks for the feedback. Yes, I will eventually remove the workaround, but I probably won't be able to do that for a long, long, long time (ie. after Vim 7.4 comes out) because otherwise it will just generate support tickets.
Add a comment
Comments are now closed for this issue.