Error Reproduction

1. Place cursor at the bottom of the gundo pane like below:

2. Press j
3. You'll get below:

Error detected while processing function <SNR>125_GundoPython:
line    4:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/HyeonKim/.dotfiles/.vim/plugged/vim-mundo/autoload/gundo.py", line 777, in GundoMove
    minidx = min(idxs)
ValueError: min() arg is an empty sequence

Cause

generate function makes trailing empty line

[
    ['@ ', '[1] <1 min ago +\\n\\n+'],
    ['| ', ''],
    ['o ', '[0] Original   '],
    ['  ', '']
]

Solutions

1. Don't let ascii function make empty line
2. Don't let generate function make empty line
3. Don't let GundoRenderGraph function render empty line

Hi, it seems during the rename you might have forgot at least two files. The first rename caused an rsync I was running on my plugged dir to crash, since it pointed to a non-existent file.

• tests/vim_test/plugin/gundo.vim -> tests/vim_test/plugin/mundo.vim, link should be remade as it still points to gundo.vim
• tests/vim_test/plugin/gundo_test_utils.vim -> tests/vim_test/plugin/mundo_test_utils.vim

More generally, I might suggest simply having multiple set rtps in your vimrc_test instead of trying to link everything into one plugin setup. You could for instance, use a directory under /tmp as a staging area for test depenencies/vimrc, then simply make sure the rtp is correct. Requires generating the vimrc for test machine.

If you want an example, see here. Uses vader instead of UT.

Situation:

When viewing a buffer's undo tree via Mundo and splitting the window and opening a new terminal in it I'm unable to select text in the terminal window. Neovim exits the visual mode after the first key stroke.

Just when Mundo is open. When I close, everything's working fine.

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun  2 2016 10:02:05)
Included patches: 1-1868
Modified by <[email protected]>
Compiled by <[email protected]>
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +tag_binary
+arabic          +file_in_path    +mouse_sgr       +tag_old_static
+autocmd         +find_in_path    -mouse_sysmouse  -tag_any_white
-balloon_eval    +float           +mouse_urxvt     -tcl
-browse          +folding         +mouse_xterm     +termguicolors
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+channel         +gettext         -mzscheme        +textobjects
+cindent         -hangul_input    +netbeans_intg   +timers
-clientserver    +iconv           +packages        +title
-clipboard       +insert_expand   +path_extra      -toolbar
+cmdline_compl   +job             +perl/dyn        +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      +lua/dyn         +rightleft       +windows
+diff            +menu            +ruby/dyn        +writebackup
+digraphs        +mksession       +scrollbind      -X11
-dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     -xim
+emacs_tags      -mouseshape      +startuptime     -xsmp
+eval            +mouse_dec       +statusline      -xterm_clipboard
+ex_extra        +mouse_gpm       -sun_workshop    -xterm_save
+extra_search    -mouse_jsbterm   +syntax          -xpm
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim74"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -g -pipe -Wall -Werror=format-security -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: gcc   -L. -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,--enable-new-dtags -Wl,-z,relro   -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -Wl,--as-needed -o vim        -lm -lnsl  -lselinux   -lncurses -lacl -lattr -lgpm -ldl   -Wl,--enable-new-dtags -Wl,-z,relro  -Wl,-z,relro  -fstack-protector-strong -L/usr/local/lib  -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc        

Invoking MondoToggle results in the message

Mundo requires Vim to be compiled with Python 2.4+ 

Hi,

I was trying to open Gundo today and here were the error messages it gave me:

"__Gundo_Preview__" [New File]
Error detected while processing function gundo#GundoToggle..<SNR>183_GundoToggle..<SNR>183_GundoOpen..<SNR>183_GundoPyt
hon:
line    2:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/phongvcao/.vim/bundle/vim-mundo/autoload/gundo.py", line 631, in GundoRenderGraph
    result = generate(walk_nodes(dag), asciiedges, nodesData.current(), verbose, len(header)+1, first_visible_line, las
t_visible_line)
  File "/home/phongvcao/.vim/bundle/vim-mundo/autoload/gundo.py", line 304, in generate
    preview_diff = nodesData.preview_diff(node.parent, node,False,show_inine_diff)
  File "/home/phongvcao/.vim/bundle/vim-mundo/autoload/gundo.py", line 582, in preview_diff
    self.diffs[key] = one_line_diff_str('\n'.join(before_lines),'\n'.join(after_lines),maxwidth)
  File "/home/phongvcao/.vim/bundle/vim-mundo/autoload/gundo.py", line 54, in one_line_diff_str
    if len(result) + len(v) > mx:
TypeError: unorderable types: int() > str()
line    4:
E319: Sorry, the command is not available in this version: python GundoRenderPreview()
Press ENTER or type command to continue

I am using Vim 7.4 Patches 1-663 with +python3 support on Arch Linux. It seems that there have been some changes to Vim which conflict with Gundo. Also, it seems that Gundo cannot pickup the fact that I am running Vim +python3 instead of +python. The s:has_supported_python was reset to 0 everytime I launch Gundo... I hope there would be a fix soon because many users will be affected by these bugs.

The website of vim-mundo https://simnalamburt.github.io/vim-mundo/ is outdated. I need to update it someday.

TODOs

• The screencast shows gundo.vim not vim-mundo. We need to replace it with a more recent video.
• Write a tutorial for the newcomers.
• Update documentations.

To reproduce: Open the MundoToggle, then simply push ?.

Error Recieved:

Error detected while processing function <SNR>168_MundoPython:
line    4:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/starcraftman/.shell/dot/files/vim/plugged/vim-mundo/autoload/mundo.py", line 402, in 
MundoToggleHelp
    vim.command("call cursor(getline('.') - %d)" % (len(INLINE_HELP.split('\n')) - 2))
vim.error: Vim(call):E474: Invalid argument
E171: Missing :endif

What about people making the transition? Seems wrong that a plugin invalidates other.

Is Gundo incompatible with Mundo in some way. If not you should about nasty things like disable other plugin

I notice sometimes that when I select an issue in my history tree, the main file doesn't update.

For some reason, vim-mundo just got very slow for large files. This should be fixed.

Hi,

First of all, thanks for your work on this project.

I'm getting an error in MundoOpen:

Error detected while processing function mundo#MundoToggle[1]..<SNR>147_MundoToggle[7]..<SNR>147_MundoOpen[4]..provider#python3#Call:
line   18:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'initPythonModule' is not defined

echo has('python') and echo has('python3') are both 1.

Here's my py3 print(sys.path):

['/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-x86_64-linux-gnu', '/usr/lib/python3.5/lib-dynload', '/home/bird/.local/lib/python3.5/site-packages', '/usr/local/lib
/python3.5/dist-packages', '/usr/lib/python3/dist-packages', '_vim_path_']

I have also installed neovim with pip and pip3. I'm using neovim built from source, installing mundo via vundle.

$ vim -v
NVIM v0.2.1-144-g031756c
Build type: RelWithDebInfo
Compilation: /usr/bin/cc -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -O2 -g -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/home/bird/clones/neovim/build/config -I/home/bird/clones/neovim/src -I/home/bird/clones/neovim/.deps/usr/include -I/home/bird/clones/neovim/.deps/usr/include -I/home/bird/clones/neovim/.deps/usr/include -I/home/bird/clones/neovim/.deps/usr/include -I/home/bird/clones/neovim/.deps/usr/include -I/home/bird/clones/neovim/.deps/usr/include -I/usr/include -I/home/bird/clones/neovim/build/src/nvim/auto -I/home/bird/clones/neovim/build/include
Compiled by bird@bird-t460s

Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui      
For differences from Vim, see :help vim-differences

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

Strangely, Mundo still seems to work fine after this error.

I'm happy to provide any additional info.

Thanks so much!
-Alex

If 'inline mode' is off, and it's toggled with the 'i' key the 'inline diffs' are set. When you scroll to new undos though, the inline diff isn't present. Retoggling a couple times populates the inline diffs.

The Readme says:

Do you have any plan to diverge from upstream?

• Not yet. It'll always be downstream of original

But #15 made massive changes to the code to rebrand and this plugin is no longer "forked from sjl/vim-gundo" on github. Should that readme segment be removed?

I'm using the latest neovim (at the time of writing I just got the source and built it) and I get the titular error when trying to invoke Gundo.

What are the differences between this and https://github.com/mbbill/undotree ?

Also, g:mundo_inline_graph and g:mundo_help appear to do nothing.

While debugging #44 I found a function that is not defined in the codebase. I followed the git history and it looks like when the original author imported the mercurial graph implementation he didn't import that function. It must be a fairly rare that get_padding_line() is called because I don't think anyone has complained about it. I suggest we remove it.

https://github.com/simnalamburt/vim-mundo/blob/master/autoload/mundo/graphlog.py#L150

There are plans to start using python3 with neovim?

My vim 8.1 complains about the "{{{ groups in util.vim

After fixing this, it complains about the lonely closing parenthesis on line 75 of util.vim, which is not escaped.

pre-disclaimer: I know you don't like or want to work with Windows (neither do I), but this is the issue that I am encountering with VIM - Vi IMproved 8.1 (Included patches: 1-500)/MS-Windows 32-bit GUI version with OLE support at work.

Problem

Keys

1. :MundoToggle
2. 20j
3. d

Result

Mundo closes the __Mundo__ window, but there is no diff.

It looks like (when I don't have guioptions+=!) that cmd prompt opens up quickly and exits. Maybe I am missing an external command like diff of something? However, when I open a cmd.exe and type which diff, I get /usr/bin/diff back.

Thanks for mundo. There are some very cool features in here (searching diffs with /, eg).

(will be written later)

I recently upgraded my Python version to 3.5 on Arch Linux. Here is what I got after opening vim-mundo:

Error detected while processing function gundo#GundoToggle[1]..318_GundoToggle[11]..318_GundoOpen[32]..318_GundoPython:
line 2:
Traceback (most recent call last):
File "", line 1, in
File "/home/phongvcao/.vim/bundle/vim-mundo/autoload/gundo.py", line 166, in GundoRenderPreview
util._output_preview_text(nodesData.preview_diff(node_before, node_after))
File "/home/phongvcao/.vim/bundle/vim-mundo/autoload/mundo/node.py", line 188, in preview_diff
before_time, after_time))
File "/usr/lib/python3.5/difflib.py", line 1177, in unified_diff
_check_types(a, b, fromfile, tofile, fromfiledate, tofiledate, lineterm)
File "/usr/lib/python3.5/difflib.py", line 1312, in _check_types
raise TypeError('all arguments must be str, not: %r' % (arg,))
TypeError: all arguments must be str, not: 1

Here are the version information:
vim-mundo: Latest from Github
Python: v3.5.0
OS: 4.2.5-1-ARCH
Vim: VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 28 2015 08:50:05) - Included patches: 1-884

Hope there will be a fix soon.

I would really like to be able to apply a patch from a previous undo onto my current state, not just having to revert completely to that state.

For example, in the image below, apply the patch made on 3 onto my current state 6, leaving me in a new state 7 with the patch from 3 applied.

Thanks for picking up the development of this plugin :-)

Would it be possible to have an option to use wdiff (or a similar word-diffing library) instead of standard diff (line diff) in the diff buffer? Wdiff usually makes more sense (for me) when I'm editing text files.

Also, would it be possible to do set wrap by default in the diff window?

I updated Mundo and encountered this error:

Error detected while processing function <SNR>141_MundoSettingsGraph[12]..<SNR>141_MundoMapGraph:
line    2:
E461: Illegal variable name: a:value
line    3:
E121: Undefined variable: a:value
...

Seems that 3eb2018 broke the plugin.

$ vim --version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Feb 13 2019 17:40:48)
macOS version
Included patches: 1-900

Need to crop it

Change gundo to mundo named variables? Maybe not - that would require those upgrading from the old plugin to rename their variables...

But - rename gundo.txt to mundo.txt, and make the changelog 3.X the official 3.0 release.

mundo used to be the fastest.

now:

1. at work (windows + gvim), it takes mundo well over 1 minute to open up
2. at home (archlinux + vim), mundo takes a few seconds to open and it makes my cpu go crazy and it blocks up when I press jjjjj even just like 4-5 times.

something bad happened. roll back or something. maybe it's just me, but it's affecting all of my vim sessinos on all the machines I use.

Hey,

thanks for taking up Gundo and making it better! :)

I have a little problem due to my keyboard layout, which uses t and r in place of j and k. Unfortunately r is mapped to rendering previews and not remappable.

Could you expose a setting for changing the keybinding, please?

Thanks again! :)

Dear All,
first of all thank you very much for this very useful and well done vim plugin.
I am using macvim (VIM - Vi IMproved 8.1 (2018 May 18, compiled Jun 11 2019 08:22:43)
macOS version Included patches: 1-1517) and, on toggling on Mundo, I frequently stumble upon the following python error:

Error detected while processing function mundo#MundoToggle[1]..117_MundoToggle[4]..117_MundoOpen[40]..117_MundoP
ython:
line 1:
Traceback (most recent call last):
File "", line 1, in
File "/Users/demichel/.vim/bundle/vim-mundo/autoload/mundo.py", line 284, in MundoMove
minidx = min(idxs)
ValueError: min() arg is an empty sequence

which can be easily be fixed by replacing

minidx=min(idxs)

with:

if len(idxs)==0:
minidx=0
else:
minidx=min(idxs)

even though I am not 100% sure it is the right way of fixing it.
By diffing against original (not fixed) version on has:
--- mundo.py 2019-07-27 11:06:43.000000000 +0200
+++ mundo_fixed.py 2019-07-27 11:01:37.000000000 +0200
@@ -281,7 +281,10 @@
idxs.append(idx2)
if idx3 != -1:
idxs.append(idx3)
- minidx = min(idxs)
+ if len(idxs)==0:
+ minidx=0
+ else:
+ minidx = min(idxs)
if idx1 == minidx:
vim.command("call cursor(0, %d + 1)" % idx1)
elif idx2 == minidx:

best regards,
Cristiano

Ideal behavior:

1. Start vim with no file. Make a few changes.
2. call :MundoShow. Changes should be seen.
3. open a new file :e new.txt.
4. The mundo window still reflects the undo state of the empty buffer - ideally it would show the new/empty undo history of new.txt.

For some reason after the d diff with change feature is used the main Gundo window doesn't appear after subsequent Gundo toggles.

When searching for pattern in undo history and there are no results, the following error is thrown

Error detected while processing function <SNR>76_MundoPython:
line    2:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\\Users\\Marko\\vimfiles\\plugged\\vim-mundo\\autoload/mundo.py", line 272, in MundoSearch
    MundoNextMatch()
  File "C:\\Users\\Marko\\vimfiles\\plugged\\vim-mundo\\autoload/mundo.py", line 280, in MundoNextMatch
    MundoMatch(1)
  File "C:\\Users\\Marko\\vimfiles\\plugged\\vim-mundo\\autoload/mundo.py", line 306, in MundoMatch
    undochanges = nodesData.preview_diff(nmap[version].parent, nmap[version])
KeyError: 6

Just switched from gundo to mundo and fixed up the binding and the settings. I have vim set to highlight trailing whitespace:

highlight ExtraWhitespace ctermbg=red guibg=red

The Mundo main display seems to have trailing whitespace on every line while the Gundo main display did not. So in Mundo I get red blocks after each "ago" and on each of the tree drawing lines while I don't see that with Gundo.

Interestingly, the patch display in Mundo doesn't seem to have any lines with trailing whitespace, even if it should. It seems as if something is specifically stripping it. In Gundo the patch display always seems to have one or two lines that end in spaces (and are highlighted as such).

Greetings,
I was happily using Gundo when suddenly it failed working. I have researched the web and found vim-mundo with new energies and coders. So I made the switch. But there still seems to be a problem: when I enter :MundoToggle I get the following error message:
E117: Unknown function: mundo#MundoToggle.

Same for MundoShow (see subject line).
I am on Debian, my vim is effectively built with support for python:
vim --version gives -L/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu
and I have python2.7 and python3 installed.

What can I do to fix this ?
Thank you for your endeavours,
Filippo

I very much appreciate Vim's vertical diff split. Is it possible to have the undo/redo preview window be split into two and shown using vertical diffsplit?

I came up with this somewhat hacky method of keeping the auto preview behaviour without rendering a diff for every node in the tree. Diffs are only rendered when the cursor remains on a node for 400 ms.

let g:mundo_auto_preview = 0
set updatetime=400

augroup mundo_auto_preview
    autocmd!
    autocmd CursorHold __Mundo__ call feedkeys('r','t')
augroup end

If anyone has any ideas on how to implement this without updatetime and would want this feature, I'd be happy to implement it properly and submit a PR.

When the gundo window is first opened it paints the entire undo history to the window, which can be slow for large undo histories. Render only what is visible to speed this up. We're doing the same thing now for the g:gundo_inline_undo feature, is its a bit slow. Do the same thing for the tree itself.

It also appears to jump out of the main screen after ? is pressed. The 'top' line you can jump to appears to be correct in the Gundo screen, but the help section is not rendered.

Consider using vader.vim as @starcraftman suggested in #31

v3.0.0 is the most recent tagged release but it contains #30. That looks really bad to new users switching from gundo since checking the help is one of the first things they'll do. It was the first thing I did and I immediately ditched mundo thinking it was an experimental fork. It wasn't until I considered reporting the issue that I found it was already fixed.

Could 67ab896 (the fixing commit) get tagged as v3.0.1? The only additional change is 404a8e8 which is another namechange doc update.

(I'm glad I stuck around: the diff searching is awesome!)

I don't know if it's even possible, but I would love to see some functionality that would allow me to see a tree for selected line(s). In your opinion, how hard would it be to implement this feature? I'd gladly help.

To reproduce:

1. Open a file, and open the mundo window (:MundoShow). Go back to the buffer's window that the undo tree is about.
2. Using the unimpaired plugin, type the ]<space expansion (adds a new line to the document, without moving the cursor).

The undo tree does not update until you move the cursor.

The error occurs when you're trying to search (with /) a place in the undo history which also happens to have a ^@ aka null character in one of the changed lines. The place of the null character on the line is irrelevant, it just has to be somewhere in a + or - line.

The error is easy to reproduce:

• Start editing a new file
• Type the line (use CTRL-V CTRL-J, for typing the ^@): test^@
• Exit insert mode so the changes are in different undos:
• Make a 2nd line with the text: otherline
• Open Mundo and /test
• This error happens:

Error detected while processing function <SNR>54_MundoPython:
line    1:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/eero/.dotfiles/vim/plugged/vim-mundo/autoload/mundo.py", line 306, in MundoSearch
    MundoNextMatch()
  File "/Users/eero/.dotfiles/vim/plugged/vim-mundo/autoload/mundo.py", line 314, in MundoNextMatch
    MundoMatch(1)
  File "/Users/eero/.dotfiles/vim/plugged/vim-mundo/autoload/mundo.py", line 344, in MundoMatch
    match_index = vim.eval('match("%s",@/)'% change.replace("\\","\\\\").replace('"','\\"'))
ValueError: embedded null byte

• sjl/gundo.vim#30
• sjl/gundo.vim#29
• sjl/gundo.vim#28
• sjl/gundo.vim#27
• dsummersl/gundo.vim

In the doc, title for section 3.14 is g:mundo_inline_graph.
It should be g:mundo_inline_undo.

Or vice-versa.

Thanks for the nice plugin btw.

Steps:

1. Open file
2. Open Mundo
   - colors show up correctly
3. Close Mundo
4. :so $MYVIMRC
5. Open Mundo
   - Mundo is black and white

Should Mundo be added to the vim-airline integrations?

What kind of information would be the most interesting to have?

See @dsummersl comment here: #39 (comment)

Gundo integration in vim-airline: https://github.com/vim-airline/vim-airline/blob/master/autoload/airline/extensions.vim#L24

Not sure if the problem comes from vim-airline, Mundo, or both.

When I toggle Mundo, my vim-airline status bar is moved inside of the Mundo tree.

Before opening Mundo (the grey bar at the bottom is tmux, do not pay attention to it):

After opening Mundo (with g:mundo_preview_bottom = 1):

When trying to run MundoToggle on the latest master branch with the Vim provided by Centos7, I receive the following error:

Error detected while processing function mundo#MundoToggle..<SNR>27_MundoToggle..<SNR>27_MundoOpen..<SNR>27_MundoClose:
line    1:
E117: Unknown function: win_getid
E116: Invalid arguments for function win_id2tabwin(win_getid())
E15: Invalid expression: win_id2tabwin(win_getid())

Version output:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Apr 10 2018 23:54:40)
Included patches: 1-160, 399, 402-403, 1099
Modified by <[email protected]>
Compiled by <[email protected]>
Huge version without 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         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con      -lua             +rightleft       +windows
+diff            +menu            +ruby/dyn        +writebackup
+digraphs        +mksession       +scrollbind      -X11
-dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     -xim
+emacs_tags      -mouseshape      -sniff           -xsmp
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        +mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim74"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -g -pipe -Wall -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L. -Wl,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE  -Wl,-z,relro  -L/usr/local/lib -Wl,--as-needed -o vim        -lm -lnsl  -lselinux  -lncurses -lacl -lattr -lgpm -ldl   -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE  -fstack-protector  -L/usr/lib64/perl5/CORE -lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc

It looks like vim 7.4 doesn't support get_winid:

E149: Sorry, no help for get_winid()

I'm still able to use this package by reverting to v3.0.0, so it's not a major issue, but it seems as though our of the box support for vim 7.4 and below has been broken.