Figure out if the luajit incompatibility is a blocker about color_coded HOT 8 CLOSED

One issue with Python is that some systems (like Arch linux) actually use python to mean python 3. Why? Because it's been out for years...

The first step I want to take on this ticket is to prevent compilation of color_coded if luajit is present in vim. I should be able to get to that tonight and it will at least allow people to realize what's going on before they get hard crashes.

In the ideal case, we don't need a middle language at all: we go directly from VimL to C++. I remember seeing there were some plugins which allowed rudimentary support for this; if it turns out to be more reliable than Lua, we might consider just doing that.

from color_coded.

@jeaye I've checked that too in the past, but libcall() and enhacements won't prevent this thing I've sadly gave up long ago.

from color_coded.

The initial topic about that is also of concern.

from color_coded.

To sum the libcall option up. Last time I checked, raw libcall can't maintain context throughout calls since it loads/unloads the dynamic library for each function call. libcallex just hides this a bit by adding an extra level of indirection, you can load libraries and maintain state, but in any case at each function call you'll still be loading and unloading the libcallex library.

from color_coded.

One issue with Python is that some systems (like Arch linux) actually use python to mean python 3. Why? Because it's been out for years...

It seems that the vim package on Archlinux is built with python 2. https://www.archlinux.org/packages/extra/x86_64/vim/ + https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/vim#n114

AFAIK, most vim's build with python 2 since a lot of them are extending into C API. In practice, I'm guessing there isn't much motivation to build vim with python 3 extension support. Correct me if I'm wrong - are there any python 3 vim addons out there?

from color_coded.

@oblitum Do you think neovim would be interested in your enhanced VimL -> C marshalling suggestions?

Anyway, this is still an open issue I'd like to get resolved before the next "release." ( see https://github.com/jeaye/color_coded/milestones/0.1 ) One added benefit of moving to Python would be better NeoVim support, even if we're not using the provided asynchronous API. However, since we'll want to use that API, and that will require some hefty changes in the VimL -> C++ binding, perhaps it's not considered much of a benefit after all.

The big drawback of moving to Python is all the code that's required in order to do so (see YCM's binding work linked above). In comparison, the Lua bindings are very light.

from color_coded.

@jeaye I'm not sure (I have no idea how neovim plugin system works since I'm not adopting it for now) and also, at that time just some sketch of an idea started to be drawn but didn't evolve, and currently I don't have much time to work on it. Despite this, IMO, that issue with libcall, the only pure C interface, is sure a defect, sadly.

Regarding the topic of moving the codebase to something different, my only advice is just to take care (python 2 vs 3, deploy, etc), python is such a pain, a lot of issues in YCM is solely because of python, so it's best to do it the right way. I personally don't matter whether neovim is biased for python, I hope it's not (I have even heard of Haskell plugins there).

It's sad no one has given the proper care for C bindings in VIM, it has got +python, +ruby, +lua, ... why no one did +c instead of only having the broken +libcall, it miss that.

from color_coded.

FYI: The Homebrew forumula for MacVim recently changed to require LuaJIT as a dependency where it used to be optional and is now configured to build with the --with-luajit option with no way of disabling it (other than building MacVIM outside of Homebrew).

VIM - Vi IMproved 8.1 (2018 May 18, compiled Nov 25 2018 13:35:57)
macOS version
Included patches: 1-280
Compiled by Homebrew
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl               +farsi             +mouse_sgr         -tag_any_white
+arabic            +file_in_path      -mouse_sysmouse    -tcl
+autocmd           +find_in_path      +mouse_urxvt       +termguicolors
+autochdir         +float             +mouse_xterm       +terminal
-autoservername    +folding           +multi_byte        +terminfo
+balloon_eval      -footer            +multi_lang        +termresponse
+balloon_eval_term +fork()            -mzscheme          +textobjects
+browse            +fullscreen        +netbeans_intg     +timers
++builtin_terms    -gettext           +num64             +title
+byte_offset       -hangul_input      +odbeditor         +toolbar
+channel           +iconv             +packages          +transparency
+cindent           +insert_expand     +path_extra        +user_commands
+clientserver      +job               +perl              +vartabs
+clipboard         +jumplist          +persistent_undo   +vertsplit
+cmdline_compl     +keymap            +postscript        +virtualedit
+cmdline_hist      +lambda            +printer           +visual
+cmdline_info      +langmap           +profile           +visualextra
+comments          +libcall           -python            +viminfo
+conceal           +linebreak         +python3           +vreplace
+cryptv            +lispindent        +quickfix          +wildignore
+cscope            +listcmds          +reltime           +wildmenu
+cursorbind        +localmap          +rightleft         +windows
+cursorshape       +lua               +ruby              +writebackup
+dialog_con_gui    +menu              +scrollbind        -X11
+diff              +mksession         +signs             -xfontset
+digraphs          +modify_fname      +smartindent       +xim
+dnd               +mouse             +startuptime       -xpm
-ebcdic            +mouseshape        +statusline        -xsmp
+emacs_tags        +mouse_dec         -sun_workshop      -xterm_clipboard
+eval              -mouse_gpm         +syntax            -xterm_save
+ex_extra          -mouse_jsbterm     +tag_binary
+extra_search      +mouse_netterm     +tag_old_static
   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 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang   -L. -L.  -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lm  -lncurses -liconv -framework AppKit  -pagezero_size 10000 -image_base 100000000 -L/usr/local/opt/luajit/lib -lluajit-5.1 -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl  -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin -lpython3.7m -framework CoreFoundation  -framework Ruby

from color_coded.