jeaye / color_coded Goto Github PK

Though lines may be folded, color_coded still only highlights the line ranges that would fit in the window without folding. I'm not actually sure if there is a way to handle this, but it's an issue nontheless.

I haven't found a way to determine which code is folded in an optimal manner. Furthermore, I haven't found a way to determine when folds are opened and closed (there is no vim event), so I'd need to repeatedly calculate the open/closed ones. Right now, all folded lines within the window's line range are highlighted; I'm sure this can be optimized.

So now that the repo includes boost parts, that old way of checking for system's boost is not working anymore since currently it's being picked over the embedded one, which may generate compatibility issues with boost.

sudo apt-get install libclang-3.6-dev was a dependency for me. "clang-c/cxstring.h" was requested.

Can anyone on ubuntu confirm?

Tracking API changes...

Building bin/libcolor_coded_boost_system.a
 Compiling src/error_code.cpp
In file included from src/error_code.cpp:16:
In file included from include/boost/system/error_code.hpp:14:
In file included from include/boost/system/config.hpp:13:
In file included from /home/reuben/.vim/bundle/color_coded/lib/boost/config/include/boost/config.hpp:44:
/home/reuben/.vim/bundle/color_coded/lib/boost/config/include/boost/config/select_stdlib_config.hpp:18:12: fatal error: 
  'cstddef' file not found
#  include <cstddef>
       ^
1 error generated.
Makefile:27: recipe for target 'src/error_code.cpp.o' failed
make[1]: *** [src/error_code.cpp.o] Error 1
Makefile:203: recipe for target 'bin/libcolor_coded_boost_system.a' failed
make: *** [bin/libcolor_coded_boost_system.a] Error 2

OS: Sabayon amd64 (Gentoo derivative)
Compiler: Clang 3.5

As a minor aside, what is the reason for requiring GCC 4.9 (if not using clang)? It's still pretty new and immature, IMO. (Not to mention it's not in the stable repository for many distributions.)

Running latest version of MacVim and color_coded.
Coloring works for most part, but when vim tries to send a 'beep' signal to terminal it crashes.

This is what OSX reports: Report for vim

For example this happens when I am at the end of a file and keep pressing j!

Here are output of vim --version and list of libraries both vim and color_coded are linked against:
diag info

I can reproduce this by disabling all other plugins except for color_coded and NeoBundle.

Hi,

After following all instructions as contained in the project's readme, I have been unable to correctly integrate this plugin into vim. Upon invoking the vim command within the terminal, I recieve the following ouput just before vim begins execution:

floyd@love-xpress:~$ vim
color_coded unavailable: requires lua
Press ENTER or type command to continue

I can confirm that lua has also been installed on my laptop with the following output:

floyd@love-xpress:~$ lua -v
Lua 5.2.3 Copyright (C) 1994-2013 Lua.org, PUC-Rio

... and that a correct version of vim too has been installed:

floyd@love-xpress:~$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled May 7 2015 14:22:51)
Included patches: 1-728
Compiled by floyd@love-xpress
Huge version with GTK2 GUI. Features included (+) or not (-):
...

Where have I gone wrong?

Thanks

• Floyd

I'm all for modern C++, but you are using C++14 library features. This is problematic as replacing a core system library is not as easy as replacing a compiler.

In particular the decay_t is not present in libstdc++4.8

For various compatibility reasons, color_coded will attempt to download a known version of clang. This may add time to your configuration process, but it offers more stability across multiple platforms.

Is it possible for clang to look for a particular version of llvm / clang on the system? What would be the possible issues that could arise?

• Add NeoBundle directive to pull and build via cmake.
• Test on FreeBSD, Debian

I get these results, due to the fact that I have multiple Lua versions installed on my system (OSX 10.10.2), managed with homebrew:

j@w1x8:~/.vim/bundle/color_coded {(master)}
$ make
Tracking API changes...

Building bin/libcolor_coded_boost_system.a
Compiling src/error_code.cpp
Linking bin/libcolor_coded_boost_system.a
Building bin/libcolor_coded_boost_filesystem.a
Compiling src/codecvt_error_category.cpp
Compiling src/operations.cpp
Compiling src/path.cpp
Compiling src/path_traits.cpp
Compiling src/portability.cpp
Compiling src/unique_path.cpp
Compiling src/utf8_codecvt_facet.cpp
Linking bin/libcolor_coded_boost_filesystem.a
Building bin/color_coded.so
Compiling src/main.cpp
src/main.cpp:3:12: fatal error: 'lua.h' file not found
#include <lua.h>
^
1 error generated.
make: *** [src/main.cpp.o] Error 1

$ ls /opt/local/lib/lua
/opt/local/lib/liblua.5.1.5.dylib /opt/local/lib/liblua.5.2.dylib /opt/local/lib/liblua.dylib /opt/local/lib/libluajit-5.1.2.0.3.dylib /opt/local/lib/libluajit-5.1.dylib
/opt/local/lib/liblua.5.1.dylib /opt/local/lib/liblua.5.3.0.dylib /opt/local/lib/liblua5.1.dylib /opt/local/lib/libluajit-5.1.2.dylib
/opt/local/lib/liblua.5.2.3.dylib /opt/local/lib/liblua.5.3.dylib /opt/local/lib/libluabind.dylib /opt/local/lib/libluajit-5.1.a

/opt/local/lib/lua:
5.1 5.2

/opt/local/lib/luarocks:
rocks
j@w1x8:~/.vim {}
$ ls /opt/local/include/lua
/opt/local/include/lua.hpp

/opt/local/include/lua-5.1:
lauxlib.h lua.h lua.hpp luaconf.h lualib.h

/opt/local/include/lua-5.3:
lauxlib.h lua.h lua.hpp luaconf.h lualib.h

/opt/local/include/lua5.1:
lauxlib.h lua.h lua.hpp luaconf.h lualib.h

/opt/local/include/lua5.2:
lauxlib.h lua.h lua.hpp lua5.2 luaconf.h lualib.h

/opt/local/include/lua5.3:
lauxlib.h lua.h lua.hpp luaconf.h lualib.h

/opt/local/include/luabind:
adopt_policy.hpp container_policy.hpp exception_handler.hpp iterator_policy.hpp open.hpp scope.hpp weak_ref.hpp
back_reference.hpp copy_policy.hpp from_stack.hpp lua_include.hpp operator.hpp shared_ptr_converter.hpp wrapper_base.hpp
back_reference_fwd.hpp dependency_policy.hpp function.hpp luabind.hpp out_value_policy.hpp tag_function.hpp yield_policy.hpp
class.hpp detail get_main_thread.hpp make_function.hpp prefix.hpp typeid.hpp
class_info.hpp discard_result_policy.hpp get_pointer.hpp nil.hpp raw_policy.hpp value_wrapper.hpp
config.hpp error.hpp handle.hpp object.hpp return_reference_to_policy.hpp version.hpp

/opt/local/include/luajit-2.0:
lauxlib.h lua.h lua.hpp luaconf.h luajit.h lualib.h

Good work so far @jeaye !

I'm primarily using this to read / study open source C projects.

• I don't want to break compatibility with C++ projects by putting a .color_coded in home,
• if it's the case of /usr/src, is it the expectation for people viewing their FreeBSD source tree to put in a .color_coded there?
• Should user's be expected to pepper .color_coded in their open source projects just to get c working? What if I'm just reading code?
• Do I need to specially go add a global gitignore and a create a custom script to automatically seed .color_coded to my projects? (thankfully I keep most code in a language-specific directory).

If we're not seeing eye to eye on .color_coded and not having some sort of mechanism to handle C / C++ case by default, I can give a go at a PR.

Just a suggestion, I haven't looked at your code. When .color_coded isn't present, you could fallback to parsing .ycm_extra_conf.py flags var, just need to read all the lines and strip quotes/commas.

My system's clang is the HEAD one and color_coded is segfaulting with it. I'll try to debug it when I have time but I guess it should be taken it account since it may get same behavior on clang 3.6.

The reason the system libclang is being loaded and not the one embedded by the plugin is because of rpath settings.

You may take a look at these issues and YCM code to learn how it may be fixed:

ycm-core/ycmd#65
ycm-core/ycmd#66

I have run install_name_tool -change @rpath/libclang.dylib ../clang+llvm-3.5.0-macosx-apple-darwin/lib/libclang.dylib bin/color_coded.so to force it to load the embedded lib.

Add documentation to README for freebsd installation.

There is currently an issue where, in certain cases, the system's libclang.so will be loaded instead of the one shipped with color_coded. This can cause undefined behavior, crashes, etc. Furthermore, if the system doesn't have a libclang.so, color_coded may not work at all. A good solution would be to statically link clang into color_coded in order to remove the dynamic dependency altogether.

When scrolling, it seems that color_coded doesn't always CursorMoved events, since the cursor may not move when scrolling. Furthermore, it seems there is no event specifically for mouse scrolling. I'm not sure how this can be handled.

Hi ! First of all I must say I was very happy to find out today about your plugin, and I thank you for your work. But sadly I have been struggling with an issue when trying to use it.

I installed the plugin using Vundle, went into my ~/.vim/bundle/color_coded and accordingly to the README did :

mkdir build; cd build; cmake ..; make && make install

All went fine, it downloaded clang, compiled the code and installed it as ~/.vim/bundle/color_coded/bin/color_coded.so. I can even cd in the directory containing that library, do lua -l color_coded and get the LUA prompt.
Despite everything going well, when I tried to launch vim, I got the error color_coded unavailable: you need to compile it (see README.md) for some reason. I then tried to use :PluginUpdate to see if it would change anything, but since then when I try to launch vim, I get a segfault :

Vim: Caught deadly signal SEGV
Vim: Finished.
[1]    22076 segmentation fault  vim

I tried to wipe out my build and bin directory in color_coded and compile it again, it compiled fine but vim still segfaults. When I comment the line Plugin 'jeaye/color_coded' in my vimrc, vim opens fine.

I'm running Debian 8, with g++ 4.9.2, lua 5.1.5, vim 7.4.576 compiled with lua support.
I had this issue on commit d21d70f.

EDIT:
I just saw this in the README https://github.com/jeaye/color_coded#color_coded-crashes-on-startup but vim --version | grep jit prints nothing for me, so it doesn't seem to be linked.

As suggested by @griwes, it would be handy to at least integrate build cleanup into the build system, whether it's automatic or not.

At the very least, I want to make a target which will delete the downloaded clang and its extracted counterpart, which can take up several hundred megs.

Hi! After the upgrade my distro plugin has stopped working. I use Arch Linux. I found out that plugin does not work with ncurses 6.0 ( libncursesw.so.6 ). I downloaded ncurses 5.9 from Ubuntu repository and run vim (fish shell): env LD_LIBRARY_PATH=<path to ncurses 5.9 lib> vim main.cpp. It works! A similar problem with plugin clang_complete. Plugin vim-clang works with ncurses 6.0.

I would like to know your stance on adding unit tests. These could be automatically checked by travis and make it easier for potential contributors to add/modify code without breaking existing functionality. It also complements the existing documentation.
As I would like to add some tests, may I nominate Catch as our testing framework? It is fairly lightweight as it is packed up as a single header file.

[18:31:58] <pepper_chico> hey
[18:35:55] <pepper_chico> I had to apply this patch to 0.1. Usage of expand('<sfile>') inside a function call in Vim returns the name of the function. When you add :h:p etc you just get garbage, take a look at :h <sfile>
[18:36:04] <pepper_chico> it's explained there
[18:37:19] <pepper_chico> in my case, when my cwd was outside color_coded plugin directory, the s:path variable you use in that function was always my current path
[18:38:05] <pepper_chico> see ya

Tried it with SemaCodeComplete.cpp from clang codebase.

Open a C++ file in a split, close its window (don't delete the buffer), split again to original arrangement and switch to the same C++ file. You get a bunch of warnings about lost IDs.

There's a small issue with the CWD affecting color_coded's behaviour: it appears to load the .color_coded file from where it was launched, rather than the directory of the source file you're editing:

newdesktop:/home/dickon/src/omxtx/ (0) 79 $ strace -f gvim omxtx.c 2>&1 | grep '\.color_coded'
[pid 19898] open("./.color_coded", O_RDONLY) = 5
newdesktop:/home/dickon/ (0) 82 $ strace -f gvim src/omxtx/omxtx.c 2>&1 | grep '\.color_coded'
[pid 20280] open("./.color_coded", O_RDONLY) = 5

resulting in incorrect flags and whatnot being applied. I don't know what the right answer is, but felt it worth flagging. I'm fairly sure colouring behaviour shouldn't be dependent on where you launch the editor from.

Love the project. It's really helpful catching typoes.

I'm having problems similar to those described in #56, however it was not due to a conflict in lua versions -- rather, I suspect that the crashes are caused by the fact that both vim and color_coded are linked against lua 5.3, which as I gather is not yet supported:

± ldd color_coded.so | grep lua                                                                                                                                               
        liblua.so.5.3 => /usr/lib/liblua.so.5.3 (0x00007fd3f7fab000)

± ldd /usr/bin/vim | grep lua                                                                                                                                                 
        liblua.so.5.3 => /usr/lib/liblua.so.5.3 (0x00007f1915098000)

Shortly after opening, vim crashes with a SEGV.

I am using vim 7.4 and color_coded @d21d70f on Arch Linux.

On OS X, always getting:

color_coded unavailable: you need to compile it (see README.md)

I've checked the state for package.cpath just before that message, and it's correctly pointing to the library path. So I dunno why lua is failing on local loaded = pcall(require, "color_coded").

I have a C++ project which has Makefile/include dir/src dir under the project root directory.
I use Ycm-Generator to generate both .ycm_extra_conf.py and .color_coded, the generating process both runs without errors. And its output is something like
Color_coded works incorrect. The error seems like this "MySelfDefine.hpp not found."

.color_coded
-x
c++
-DNDEBUG
-I/usr/include/openni2
-I/usr/local/cuda/include
-I/usr/local/include
-Iinclude or -I./include both error, -I/home/user/project_path/include works correctly.
-Wall
-Werror

YCM works fine.

.ycm_extra_conf.py
flags = [
'-x',
'c++',
'-DNDEBUG',
'-I/usr/include/openni2',
'-I/usr/local/cuda/include',
'-I/usr/local/include',
'-Iinclude',
'-Wall',
'-Werror',
]

color-coded sporadically creates a kind persistent word selection. I mean, some text with selection background that I'm unable turn off.

They all suck, looks like I'll be putting in CMake.

I'm getting a segfault when starting a freshly compiled Vim with color_coded enabled.

Output:

$ vim
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault

Backtrace :

(gdb) run
Starting program: /usr/local/bin/vim 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
b
Program received signal SIGSEGV, Segmentation fault.
0x00007fffedd26e33 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
(gdb) bt
#0  0x00007fffedd26e33 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#1  0x00007fffedd19c22 in lua_setglobal () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#2  0x00007fffee22bab9 in luaopen_color_coded () from /home/tux3/.vim/bundle/color_coded/bin/color_coded.so
#3  0x00007ffff557da88 in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
#4  0x00007ffff55c0dfc in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
#5  0x00007ffff557da88 in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
#6  0x00007ffff55c0f60 in lua_pcall () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
#7  0x00000000005c73b2 in ex_lua ()
#8  0x000000000049431d in do_cmdline ()
#9  0x000000000046a8e0 in ?? ()
#10 0x000000000046b362 in ?? ()
#11 0x000000000046f3f3 in ?? ()
#12 0x000000000046de38 in ?? ()
#13 0x000000000046e004 in ?? ()
#14 0x000000000046e26e in ?? ()
#15 0x000000000046ee75 in ?? ()
#16 0x000000000046eff5 in ?? ()
#17 0x000000000046f94e in ?? ()
#18 0x0000000000476401 in ex_let ()
#19 0x000000000049431d in do_cmdline ()
#20 0x0000000000488cd2 in do_source ()
#21 0x0000000000488018 in do_in_runtimepath ()
#22 0x0000000000438f00 in main ()

~/.vimrc:

" General
set nocompatible
syntax on
set t_Co=256
set ttimeoutlen=50

" Start Vundle
filetype off
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'gmarik/Vundle.vim'

" Airline
"Plugin 'bling/vim-airline'
set laststatus=2
let g:airline_powerline_fonts = 1
if !exists('g:airline_symbols')
        let g:airline_symbols = {}
endif

" color_coded
Plugin 'jeaye/color_coded'   

let g:color_coded_enabled = 1 

" End Vundle
call vundle#end()            " required
filetype plugin indent on

Vim version:

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Apr  6 2015 15:04:58)
Included patches: 1-691
Compiled by tux3
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
+balloon_eval    +float           +mouse_urxvt     -tag_any_white
+browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
+clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      +toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python/dyn      +viminfo
+cscope          +lispindent      +python3/dyn     +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  +lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      +X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
+emacs_tags      +mouseshape      -sniff           +xsmp_interact
+eval            +mouse_dec       +startuptime     +xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    +xpm
   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"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"
 f-b for $VIMRUNTIME: "/usr/local/share/vim/vim74"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2    -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: gcc   -L. -Wl,-z,relro -L/build/ruby2.1-NaMyQG/ruby2.1-2.1.5/debian/lib -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E   -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype  -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lnsl  -lselinux   -ldl  -L/usr/lib/x86_64-linux-gnu -lluajit-5.1 -Wl,-E  -fstack-protector -L/usr/local/lib  -L/usr/lib/x86_64-linux-gnu/perl/5.20/CORE -lperl -ldl -lm -lpthread -lcrypt    -lruby-2.1 -lpthread -lgmp -ldl -lcrypt -lm

Lua is broken on debian (and possibly other) machines.

See https://issues.apache.org/jira/browse/THRIFT-2914.

The current makefile is set to -llua, however, debian will require -llua5.2 for the shared library.

Here's the thing, after carefully examination which plugin had caused the following issues as below screenshots indicated, finally I find it was color_coded which brings me that weird highlight.

Does anyone know how this happened and how to remove this highlight feature?

a. After used color_coded.

Plugin 'jeaye/color_coded'

b. Before used color_coded.

" Plugin 'jeaye/color_coded'

The README explicitly mentions lua5.1 but does not consider vim builds that are linked against a different version. This can lead to bugs such as #56. We should mention that the user may have to install lua5.2 or higher depending on how their vim version was built.

Unfortunately, this is not that easy to find out. vim --version might have that information in its linker flags like in #56, but that is not always the case.

Just so we both don't forget about this experiment:

On Sat, Mar 28, 2015 at 10:35:46PM -0700, Francisco Lopes wrote:
[1]@jeaye yeap, I'm planning to use it since I find it much better. The
sole missing thing I dislike about it is trying to handle colorscheme
instability. As you already know it's quite broken while typing, if there
was a way to restrict this, it would be perfect. I was thinking of
alternatives myself, like, trying to refresh highlighting in key
situations solely, like when going to normal mode, or when moving cursor line,
or refreshing just when there're no errors in the TU, I don't know in
truth =)

Seems reasonable. How about an option for realtime (incomplete) updating which defaults to on? It seems like it'd be simple enough to guard the functionality between two cases:

1. Incomplete highlighting is enabled
2. There was a successful compilation

Currently color_coded applies the "Keyword" highlight very coarsely, with no distinction between different types of keywords. This is a problem for me because I would like to have void, int, and other builtin type names highlighted as types instead of keywords for consistency. Being that the set of keywords is reasonably small and doesn't change often, perhaps an option could be added to skip highlighting keywords altogether and just let vim's syntax files handle them?

This is a vim bug: vim/vim#434

I am experiencing what is probably a niche error, but it's a bit frustrating nonetheless.

Prerequisites: Vim with color_coded, tmux

Steps to reproduce:

1. Open Vim on a file that causes color_coded to be loaded
2. Immediately open a new tmux pane or window
3. Vim segfaults.

Here is my gdb output:

#0  0x0000000000463241 in set_ref_in_item ()                                                                                                                                                      
#1  0x00000000005d4e09 in ?? ()
#2  0x00007ffff5397950 in ?? () from /usr/lib/liblua.so.5.3
#3  0x00007ffff5397d0b in ?? () from /usr/lib/liblua.so.5.3
#4  0x00007ffff539386e in lua_callk () from /usr/lib/liblua.so.5.3
#5  0x00000000005d64f8 in set_ref_in_lua ()
#6  0x000000000046ccfd in garbage_collect ()
#7  0x0000000000532b77 in mch_inchar ()
#8  0x00000000005ae280 in ui_inchar ()
#9  0x00000000004c257f in inchar ()
#10 0x00000000004c457d in ?? ()
#11 0x00000000004c4dce in vgetc ()
#12 0x00000000004c5229 in safe_vgetc ()
#13 0x000000000051205d in normal_cmd ()
#14 0x00000000005ef005 in main_loop ()
#15 0x000000000043a0b0 in main ()
(gdb)  

This error doesn't (usually) occur if color_coded is given a few seconds to initialize. I think I've encountered it once or twice even with a fully loaded file, but I haven't been able to reliably reproduce it.

This is not a huge hassle if I remember just to wait a short while after opening vim, but it can be annoying and is probably preventable.

I tried to compile on Fedora 21. I got some error messages:

include/clang/token.hpp:62:16: error: ‘CXType_IncompleteArray’ was not declared in this scope

... so I used the Fedora package clang-devel-3.5.0-6.fc21.i686

Then it compiled OK, but I still get "color_coded unavailable: you need to compile it"

I did an "strace" on vim, and it loads OK:

open("/home/user/.vim/bin/color_coded.so", O_RDONLY|O_CLOEXEC) = 4

... then loads the dependent libraries (libz, libcurses, libstdc++ , libgcc_s), but then issues the error message: "color_coded unavailable: you need to compile it".

For some reason "pcall" returns "not loaded", and I don't know why.

OSX 10.10.2
Lua 5.2.3

samm-mbp ~/.vim/bundle/color_coded % make                                                                                                                                                            git:master
Tracking API changes...

Building bin/libcolor_coded_boost_system.a
Linking bin/libcolor_coded_boost_system.a
Building bin/libcolor_coded_boost_filesystem.a
Linking bin/libcolor_coded_boost_filesystem.a
Building bin/color_coded.so
 Compiling src/main.cpp
src/main.cpp:3:12: fatal error: 'lua.h' file not found
  #include <lua.h>
           ^
1 error generated.
make: *** [src/main.cpp.o] Error 1

Issue: #25 (comment)

[neobundle] Uncaught error while sourcing "color_coded": Vim(execute):E121: Undefined variable: b:current_syntax in function color_coded#enter, line 7

Here is the profile.log and vim version here from the error: https://gist.github.com/tony/a23eb36f188102120df6

Will follow up on what plugin / scheme is causing this issue and the workaround.

This is most easily explained with a screenshot:

My cursorline is a lighter background, but the tokens that have been highlighted are set to the "real" background.

I am on Mac OS X Yosemite with no admin rights and little access to install things (no macports and no homebrew) therefore I have had to install libraries from scratch. I'm using Lua 5.3, installed in my home directory, despite of having lua 5.2 in the system, but for some reason, macvim could not compile with the lua system version. So I compiled it with Lua 5.3. The same for color_coded. I created an alias so lua -v gives me back the lua 5.3.0 I installed; however, which lua returns the system lua version. I don't know if this could be problematic, but I thought I would mention it. Also, I do not have luajit installed.

Whenever I open a header or a source file for C++, vim crashes with this error:

Vim: Caught deadly signal ABRT
libc++abi.dylib: terminating
                            Vim: Finished.
Vim: Double signal, exiting
Abort trap: 6

How could I obtain more information about this problem? I'm in the process of installing gdb to debug it, but I was wondering if there were other means. Also, I've read the option of running tests at the color_coded directory with make run, but I don't see any Makefile there. I did run color_coded_config_test inside the build and got this output

running group 'loading and reading of config files'
  test 0 success
  test 1 success
  test 2 failure: failed 'unexpected' (false)
  test 3 success
finished group 'loading and reading of config files'
1/4 test(s) failed

When I compiled color_coded (in the ccmake interface), I set CMAKE_INSTALL_PREFIX as ~/.vim/bundle/color_coded/install, however, all the files are installed in ~/.vim/bundle/color_coded, the default directory, could this be a problem?

Sorry I can't provide more information. I know this is related to color_coded because it only happens when it is in my .vimrc. Thanks in advance.

Due to some bugs in libclang, certain bits of code are either highlighted incorrectly or are not highlighted at all. This ticket should be used to aggregate the known instances of this and provide whether or not they've been resolved in my libclang fork.

If you find any unlisted items, please add a comment below and, if you can, provide the smallest bit of code required to reproduce the problem. Debugging libclang is far from fun.

Currently, it's best to use color_coded with vim when luajit is not installed. Having it installed has shown to be problematic, mainly causing segfaults at startup.

When trying to quit vim directly after opening a c++ file, it segfaults. This only happens about 50% of the time and I only noticed it today despite using this plugin for serveral days now.

Attaching a debugger shows that the segfault happens in std::condition_variable::wait. The only place where we wait for something is in async/queue.hpp. A possible explanation of why this is happening:

• The queue object gets destroyed
• It calls thread::detach in the destructor
• The condition variable inside work() wakes up and checks has_work_
• As the object was already destroyed, the member variable does not exist anymore and causes a segfault

I use vim-better-whitespace which is a quite useful plugin for me, but enabling color_coded seems to turn it unusable.

Though clang 3.7 is released, it's not currently usable, since they forgot/just didn't package libclang.a in the Linux x86_64 tarball. I've made an issue here: https://llvm.org/bugs/show_bug.cgi?id=24919 though, as expected, there's been no activity on it.

Upgrading to clang 3.7 will give us more C++17 support.