wincent / command-t

⌨️ Fast file navigation for Neovim and Vim
BSD 2-Clause "Simplified" License
2.74k stars 317 forks source link

Upgrade issues - MacOS Ventura - command-t.vim could not load the C extension #417

Closed noahlz closed 1 year ago

noahlz commented 1 year ago

I had to brew install something for a completely unrelated task, and now Command-T does not work. I've been using it for about 10 years and have only had to troubleshoot a few times. Also, I am a new MacOS user after they took away my trusty Ubuntu workstation and shoved a MacBook M1 in my hands (poor me, I know), please be gentle.

command-t.vim could not load the C extension.
Please see INSTALLATION and TROUBLE-SHOOTING in the help.
Vim Ruby version: 3.2.1-p31
Expected version: 2.6.10-p210
For more information type:    :help command-t-ruby

My environment:

Command-T Version:

commit 23d2860931 (HEAD -> main, origin/master, origin/main, origin/HEAD)
Author: Greg Hurrell <greg@hurrell.net>
Date:   Fri Dec 16 13:40:17 2022
$ which ruby
/usr/bin/ruby
$ ruby --version
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin22]

When I first set up Command-T on this new device, I think I had ruby issues due to using homebrew, which I think I solved by adding this to my vimrc

$ head .vimrc

" use our local version of ruby, not the system version
set rubydll=/opt/homebrew/Cellar/ruby/3.2.1/lib/libruby.3.2.dylib

$ vi --version

vi --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Feb 07 2023 11:35:56)
macOS version - arm64
Included patches: 1-1276
Compiled by Homebrew
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl               +find_in_path      +mouse_xterm       +tcl
+arabic            +float             +multi_byte        +termguicolors
+autocmd           +folding           +multi_lang        +terminal
+autochdir         -footer            -mzscheme          +terminfo
-autoservername    +fork()            +netbeans_intg     +termresponse
+balloon_eval      +fullscreen        +num64             +textobjects
+balloon_eval_term +gettext           +odbeditor         +textprop
+browse            -hangul_input      +packages          +timers
++builtin_terms    +iconv             +path_extra        +title
+byte_offset       +insert_expand     +perl              +toolbar
+channel           +ipv6              +persistent_undo   +transparency
+cindent           +job               +popupwin          +user_commands
+clientserver      +jumplist          +postscript        +vartabs
+clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +vim9script
+cmdline_hist      +langmap           -python            +viminfo
+cmdline_info      +libcall           +python3           +virtualedit
+comments          +linebreak         +quickfix          +visual
+conceal           +lispindent        +reltime           +visualextra
+cryptv            +listcmds          +rightleft         +vreplace
+cscope            +localmap          +ruby              +wildignore
+cursorbind        +lua               +scrollbind        +wildmenu
+cursorshape       +menu              +signs             +windows
+dialog_con_gui    +mksession         +smartindent       +writebackup
+diff              +modify_fname      -sodium            -X11
+digraphs          +mouse             +sound             -xfontset
+dnd               +mouseshape        +spell             +xim
-ebcdic            +mouse_dec         +startuptime       -xpm
+emacs_tags        -mouse_gpm         +statusline        -xsmp
+eval              -mouse_jsbterm     -sun_workshop      -xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary
-farsi             -mouse_sysmouse    -tag_old_static
+file_in_path      +mouse_urxvt       -tag_any_white
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe -DMACOS_X -DMACOS_X_DARWIN -g -O2 -arch arm64 -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang -arch arm64 -L/opt/homebrew/lib -o Vim -lm -lncurses -liconv /opt/homebrew/lib/libintl.a -framework AppKit -L/opt/homebrew/opt/lua/lib -llua5.4 -L/System/Library/Perl/5.30/darwin-thread-multi-2level/CORE -lperl -L/opt/homebrew/opt/python@3.11/Frameworks/Python.framework/Versions/3.11/lib/python3.11/config-3.11-darwin -lpython3.11 -framework CoreFoundation -F/System/Library/Frameworks -framework Tcl -framework CoreFoundation -lruby.3.2 -L/opt/homebrew/Cellar/ruby/3.2.0/lib

I tried various incanatations that worked in years past i.e. make \ rake \ etc. in various command-t plugin subdirectories, I also tried checking out version 5.0.5 to see if that older version worked. Rather than detail the results of those attempts, let's just say all these attempts failed and I'm just thrashing at this point.

Slightly confusing matters is the recent re-write in Lua (nice!), which seems to require neovim? In any case, I'm slightly lost.

Hoping for a few hints on how to proceed here, happy to contribute a PR with some documentation / notes (or at least I'll post a gist with instructions) once I get it working.

wincent commented 1 year ago

Slightly confusing matters is the recent re-write in Lua (nice!), which seems to require neovim? In any case, I'm slightly lost.

Sort of. In Neovim, you get to use the new Lua implementation which is faster and has a better UI. But the Ruby code is still there and can be used as a fallback, so when you run Command-T in Vim, that's the code that will get executed. (You can see the logic for this in the main entry point.) Given that a lot of Neovim/Vim users install plugins by using a plugin manager that points at the HEAD of the main/master branch of a plugin, as a plugin author I really have no choice but to maintain backwards compatibility pretty much "forever".

" use our local version of ruby, not the system version
set rubydll=/opt/homebrew/Cellar/ruby/3.2.1/lib/libruby.3.2.dylib

I've never had to use a hack like that myself, so can't really comment on the robustness of it. My approach has always been to use the same version of Ruby to do the Command-T build as Vim is using, and then I leave Vim alone. I know it's not always possible, but I generally try to avoid messing with the Ruby install on the system (eg. by installing a newer version with a Ruby version manager) at all because it tends to bring a bunch of headaches.

I tried various incanatations that worked in years past i.e. make \ rake \ etc. in various command-t plugin subdirectories

I think this is going to be the key.

Vim Ruby version: 3.2.1-p31
Expected version: 2.6.10-p210

You've got to get these versions to match, somehow. Based on your description, I gather 3.2.1-p31 is coming from Homebrew. Does it stay that way if you remove that rubydll setting? If it does, can you get that version of Ruby to activate when you run make clean && ruby extconf.rb && make? I don't know whether that means setting your $PATH or using a Ruby version manager to make sure you get the same version printed when you run ruby --version.

If you did want to use Neovim, then you could use the Lua implementation and you could forget about building the Ruby extension.

wincent commented 1 year ago

Closing due to inactivity.