sjbach / lusty Goto Github PK

I am using mru.vim plugin to get a list of my most recently used files. It would be great if LustyExplorer had an option to view/open the last X mru files that would be saved across vim sessions. (I am new to vim so maybe I am just missing an easier way to open my top 10 or so files)

Lusty is awesome! Thank you.

I just tried to install lusty explorer and gvim on windows 7 and ran into this issue. Any time I try to invoke the LustyFileSystemExplorer, I get the response below. When I tried to invoke the LustyBufferExplorer, gVim crashed. Any ideas? Is there a better way to install on Windows?

unknown encoding name - latin1
(eval):803:in `force_encoding'
(eval):803:in `run_from_path'
(eval):1:in `block in <main>'
(eval):253:in `profile'
(eval):1:in `<main>'

Here is my gVim installation version. It was installed from the Self-installing executable gvim##.exe gvim73_46.exe
listed at http://www.vim.org/download.php#pc.

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 27 2010 17:59:02)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-46
Compiled by Bram@KIBAALE
Big version with GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent 
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff 
+digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi 
+file_in_path +find_in_path +float +folding -footer +gettext/dyn -hangul_input 
+iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak 
+lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse 
+mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg +ole 
-osfiletype +path_extra +perl/dyn +persistent_undo -postscript +printer 
-profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby/dyn 
+scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop 
+syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -tgetent 
-termresponse +textobjects +title +toolbar +user_commands +vertsplit 
+virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu 
+windows +writebackup -xfontset -xim -xterm_save +xpm_w32 
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
  system gvimrc file: "$VIM\gvimrc"
    user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
    system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32   -DFEAT_CSCOPE 
-DFEAT_NETBEANS_INTG   -DFEAT_XPM_W32   -DWINVER=0x0400 -D_WIN32_WINNT=0x0400  
/Fo.\ObjGOLYHTR/ /Ox /GL -DNDEBUG  /Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME 
-DFEAT_GUI_W32 -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL 
-DDYNAMIC_TCL_DLL=\"tcl83.dll\" -DDYNAMIC_TCL_VER=\"8.3\" -DFEAT_PYTHON -DDYNAMIC_PYTHON 
-DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 
-DDYNAMIC_PYTHON3_DLL=\"python31.dll\" -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl51
2.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby191
.dll\" -DFEAT_BIG /Fd.\ObjGOLYHTR/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib 
shell32.lib gdi32.lib  comdlg32.lib ole32.lib uuid.lib /machine:i386 /nodefaultlib gdi32.lib version.lib   winspool.lib 
comctl32.lib advapi32.lib shell32.lib  /machine:i386 /nodefaultlib libcmt.lib oleaut32.lib  user32.lib      
/nodefaultlib:python27.lib /nodefaultlib:python31.lib   e:\tcl\lib\tclstub83.lib WSock32.lib e:\xpm\lib\libXpm.lib 
/PDB:gvim.pdb -debug

And Ruby installation version is ruby 1.9.1p430.

I get this error every time I try to invoke LustyExplorer:

Error detected while processing function 50_LustyFilesystemExplorerFromHereStart:
line 1:
NameError: (eval):31: uninitialized constant Lusty

Sometimes it's without the "FromHere", obviously (when not using lr)

This is a request for the feature of selecting the home row-based navigation keys for alternative layouts. In USA standard layout, the home row is "ASDFGHJKL;", but this is not the case for all layouts. For example, in the Dvorak layout, the home row is "AOEUIDHTNS".

It would be handy if the user could specify alternative layouts, either through a simple configuration setting like let g:LustyJugglerLayout = dvorak, or by specifying a mapping somehow.

I just updated Lusty yesterday (November 22) and all my commands are broken. I was just using all the default keybindings, and now when I type \lf I just get an error that LustyExplorer isn't an editor command. I tried setting LustyFilesystemExplorerDefaultMappings and LustyExplorerDefaultMappings to 1, to no avail.

I know this isn't the most informative bug report. If there is some more information I can give you, please let me know. Thanks for your work on this plugin. I think it is the best navigation plugin around!

When running view with Lusty Explorer and LustyJuggler installed, invoking the plugins results in an error.

The plugins have been checked out from the git repository and the Fetch URL is:
git://github.com/sjbach/lusty.git

The SHA for the current head in my local repo is 27d0082

For LustyJuggler:
"Error detected while processing function 10_BufferExplorerStart:"
followed by:
"Warning: changing a readonly file."
after which it seems to bring up the mini window.
For Lusty Explorer:
"Error detected while processing function 10_FilesystemExplorerStart:"
followed by:
"Warning: changing a readonly file."
After which the mini window comes up.

I am using a MacVim snapshot 51 downloaded from http://code.google.com/p/macvim/wiki/Snapshot

The output of --version is given below:

host-145:lusty lotia$ vim --version
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 21 2009 22:51:05)
MacOS X (unix) version
Included patches: 1-303
Compiled by Bjorn Winckler [email protected]
Huge version with MacVim GUI. Features included (+) or not (-):
+arabic +autocmd -balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+float +folding -footer +fork() +fullscreen -gettext -hangul_input +iconv
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent
+listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape
+mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg +odbeditor
-osfiletype +path_extra -perl +postscript +printer +profile +python +quickfix
+reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +startuptime
+statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white
-tcl +terminfo +termresponse +textobjects +title +toolbar +transparency
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace
+wildignore +wildmenu +windows +writebackup -X11 -xfontset +xim -xsmp
-xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe -DMACOS_X_UNIX -no-cpp-precomp -g -O2 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386 -arch x86_64 -D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386 -arch x86_64 -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon -lm -lncurses -liconv -framework Python -framework Ruby

Would require editing the Makefile, I'd guess.

I'd like lusty-juggler.vim & lusty-explorer.vim to be in the subdirectory plugins/ so that pathogen users are a single git clone away from installing lusty!

Otherwise, no complaints. Awesome plugins! Love that they're in Ruby, too. Yay Ruby!

It would be great to add arrow keys support to the lustyexplorer and lustyjuggler plugins. Hardcore vim users will scoff the idea, but I think it would be a good usability feature.

Hi Stephen,

Steps to reproduce:

1. Open min. 2 buffers
2. Trigger lusty-juggler
3. Press i

Lusty-juggler inserts its function calls into the document. Example output:

"":call <SNR>17_LustyJugglerKeyPressed('d')
e:call <SNR>17_LustyJugglerKeyPressed('d')
e:call <SNR>17_LustyJugglerKeyPressed('k')
:call <SNR>17_LustyJugglerKeyPressed('j')
:call <SNR>17_LustyJugglerKeyPressed('k')
:call <SNR>17_LustyJugglerKeyPressed('j')
i:call <SNR>17_LustyJugglerCancel()

Adam.

Lusty Juggler should not be listing utility buffers like, for example, Tag_List.

If LustyJuggler is activated and the user presses a key that isn't asdfghjkl; that puts the user in an editing mode, such as o or R, LustyJuggler outputs all commands to the buffer, locking up Vim. LustyJuggler should somehow block the other input keys, or exit if they are called.

Greetings. Would love to be using LustyExplorer full time, but I have a consistent problem with it throwing a ton of errors every time it's invoked while minibufexplorer's (https://github.com/fholgado/minibufexpl.vim) vim window is open. Errors that look like:

Error detected while processing function 33_AutoUpdate..33_BuildBufferList:
line 66:
E16: Invalid range
E16: Invalid range
Error detected while processing function 33_AutoUpdate..33_StartExplorer..<
SNR>33_DisplayBuffers..33_ShowBuffers..33_BuildBufferList:
line 66:
E16: Invalid range
E16: Invalid range

A real bug, or something I've failed to config properly? I'm on vim 7.3.35 on Ubuntu 11.04.

It'd be really nice to be able to get tags as one of the lusty options. I started to work on this but I'm not really sure where to go from here. It seems like it should be fairly easy but I'm not sure how to get to the tags within the ruby code.

I can't enter åäö characters when trying to create new file with under Lusty Explorer.

I also can't see åäö characters in filenames. A file named testkörning.txt would be displayed as testkorning.txt.

I'm running latest MacVim. Got up to date Ruby too but i would guess Vim will use the default version that comes with OS X Lion instead of the one i've installed through Homebrew. I'm not sure how Vim + Ruby works.

LustyJuggler seems to break vim-surround visual mode functions.

I can reproduce the behaviour in the following way:

• Run Vim with only the two plugins: LustyJuggler and surround (by tpope)
• Write something and use v for visual and select something
• Press s" and the surround plugin adds " at the beginning and the end of the selected text
• Create a new file with :enew
• Use LustyJuggler to switch back to the original file
• Now visual mode + s" does nothing

When I have a vim window open with a horizontal split and try to invoke one of the lusty functions, the window split gets pushed up all the way to the top of the window. It is so annoying that I don't end up using the horizontal splits. Can you find a way to leave the position of the horizontal split(s) in place when using the lusty functions?

Steps to reproduce the problem:
:sp
:LustyFilesystemExplorer

I use ":set mouse=a".

1. vim -c LustyBufferExplorer
2. Click on the buffer I am editing.
3. Press CTRL-W o.
4. LustyBufferExplorer doesn't work any more.

This has accidentally happened several times and I couldn't figure out how to open Lusty without restarting vim.

After triggering lusty juggler, pressing enter in insert mode will insert the string "DiscretionaryEnd" instead of a new line. This time I'm using the latest version off GitHub. ;(

If there are some files with invalid characters ruby raises an error:

invalid byte sequence in UTF-8
(eval):91:in `gsub'
(eval):91:in `regex_escape'
(eval):595:in `highlight_selected_index'
(eval):575:in `refresh'
(eval):485:in `run'
(eval):759:in `run'
(eval):768:in `run_from_path'
(eval):1:in `block in <main>'
(eval):238:in `profile'
(eval):1:in `<main>' 

I have seen this kind of errors before on Windows with codepage 936 (cp936), but I did not find out exactly how to triger this error.

The commands d and s (maybe others, but this is all I know so far) stop working as expected after LustyJuggler is invoked. Some commands like d0, d$ etc. work fine but dd doesn't work at all. I'm seeing this problem only when I use LustyJuggler along with Yankstack or YankRing(https://github.com/vim-scripts/YankRing.vim).

I think it may be due to conflicting mappings (or function calls) but I could be wrong.

I have a couple of custom mappings in my vimrc file, such as:

" Easy window navigation
map <C-h> <C-w>h
map <C-j> <C-w>j
map <C-k> <C-w>k
map <C-l> <C-w>l

When I trigger lusty juggler, some of these mappings disappear. For example <C-h> no longer does anything, and running :map <C-h> returns no result (it did before). The mapping is just gone. Running :so $MYVIMRC brings it back, but obviously I don't want to have to do that after each time I trigger lusty juggler. Ideas?

Hi.

If I load a number of files in Vim like this:

vim a.txt b.txt c.txt d.txt

I've got a.txt in the current window and the buffer list (:ls) is populated accordingly.

I can use :LustyBufferExplorer to jump to d.txt as expected.

However, when using :LustyBufferGrep the list of sources has all the expected buffers (a.txt to d.txt) but I'm unable to search within them. Only within the current one.

:LustyBufferGrep seems to only work when I've "opened" all the buffers: if I jump to another buffer LustyExplorer is now able to search within the first and the second. That's only 2 buffers but the list of sources still displays 4 buffers.

Is that the correct behaviour?

How shall I do to make it work with all loaded buffers? Say all 150 of them.

Thanks.

Lusty Juggler crashes with 'Abort trap: 6' error on OSX Mountain Lion 10.8.1

Using system Vim
Using system Ruby (ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0])
Same error happens using ruby 1.9.2p320 (2012-04-20 revision 35421) [x86_64-darwin12.1.0] installed via RVM. (RVM is clean install following Mountain Lion Upgrade).

Vim crashes when attempting to access any buffer from menu (e.g. using 'aa' or 'ss') command.

Vim --version:
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun 20 2012 13:16:02)
Compiled by [email protected]
Normal version without GUI. Features included (+) or not (-):
-arabic +autocmd -balloon_eval -browse +builtin_terms +byte_offset +cindent
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
-conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs
-dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path
+find_in_path +float +folding -footer +fork() -gettext -hangul_input +iconv
+insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape
-mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype
+path_extra -perl +persistent_undo +postscript +printer -profile +python/dyn
-python3 +quickfix +reltime -rightleft +ruby/dyn +scrollbind +signs
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
-toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
-xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -D_FORTIFY_SOURCE=0 -Iproto -DHAVE_CONFIG_H -arch i386 -arch x86_64 -g -Os -pipe
Linking: gcc -arch i386 -arch x86_64 -o vim -lncurses

Additional installed plugins:
command-t
lusty
mru
supertab
vim-colors-solarized
vim-rails

Full trace:

Process: vim [87627]
Path: /usr/bin/vim
Identifier: vim
Version: 48.1
Code Type: X86-64 (Native)
Parent Process: bash [49222]
User ID: 503

Date/Time: 2012-09-14 01:45:24.210 +0100
OS Version: Mac OS X 10.8.1 (12B19)
Report Version: 10

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
[87627] stack overflow

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff920c5d46 __kill + 10
1 libsystem_c.dylib 0x00007fff8c026eec __abort + 193
2 libsystem_c.dylib 0x00007fff8c027d43 __stack_chk_fail + 195
3 vim 0x000000010ac4f4dd 0x10ab22000 + 1234141
4 com.apple.ruby 0x000000010ad345f9 0x10ad0f000 + 153081
5 com.apple.ruby 0x000000010ad28f7a 0x10ad0f000 + 106362
6 com.apple.ruby 0x000000010ad374ad 0x10ad0f000 + 165037
7 com.apple.ruby 0x000000010ad34afb 0x10ad0f000 + 154363
8 com.apple.ruby 0x000000010ad28f7a 0x10ad0f000 + 106362
9 com.apple.ruby 0x000000010ad374ad 0x10ad0f000 + 165037
10 com.apple.ruby 0x000000010ad34afb 0x10ad0f000 + 154363
11 com.apple.ruby 0x000000010ad28f7a 0x10ad0f000 + 106362
12 com.apple.ruby 0x000000010ad374ad 0x10ad0f000 + 165037
13 com.apple.ruby 0x000000010ad28086 0x10ad0f000 + 102534
14 com.apple.ruby 0x000000010ad37f5a 0x10ad0f000 + 167770
15 com.apple.ruby 0x000000010ad38004 0x10ad0f000 + 167940
16 com.apple.ruby 0x000000010ad34afb 0x10ad0f000 + 154363
17 com.apple.ruby 0x000000010ad28f7a 0x10ad0f000 + 106362
18 com.apple.ruby 0x000000010ad374ad 0x10ad0f000 + 165037
19 com.apple.ruby 0x000000010ad37c4c 0x10ad0f000 + 166988
20 com.apple.ruby 0x000000010ad25df7 0x10ad0f000 + 93687
21 com.apple.ruby 0x000000010ad25a30 rb_eval_string + 92
22 com.apple.ruby 0x000000010ad261e5 rb_protect + 173
23 vim 0x000000010ac4ea40 0x10ab22000 + 1231424
24 vim 0x000000010ab65d56 0x10ab22000 + 277846
25 vim 0x000000010ab475df 0x10ab22000 + 153055
26 vim 0x000000010ab404c2 0x10ab22000 + 124098
27 vim 0x000000010ab3fdc5 0x10ab22000 + 122309
28 vim 0x000000010ab65d56 0x10ab22000 + 277846
29 vim 0x000000010abd01de 0x10ab22000 + 713182
30 vim 0x000000010abca4d2 0x10ab22000 + 689362
31 vim 0x000000010ab9bc38 0x10ab22000 + 498744
32 vim 0x000000010ab9b2ea 0x10ab22000 + 496362
33 libdyld.dylib 0x00007fff8a46c7e1 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x00007fff550d6860 rcx: 0x00007fff550d6848 rdx: 0x0000000000000000
rdi: 0x000000000001564b rsi: 0x0000000000000006 rbp: 0x00007fff550d6870 rsp: 0x00007fff550d6848
r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x00007fff920c7342 r11: 0x0000000000000206
r12: 0x000000010ae71b38 r13: 0x00000000000013b9 r14: 0x000000010ae71a20 r15: 0x0000000000000001
rip: 0x00007fff920c5d46 rfl: 0x0000000000000206 cr2: 0x00007fff76543fe8
Logical CPU: 0

Binary Images:
0x10ab22000 - 0x10ac8dfff vim (48.1) /usr/bin/vim
0x10ad0f000 - 0x10adceff7 com.apple.ruby (1.8.7.72 - Ruby-1.8.6.287) /System/Library/Frameworks/Ruby.framework/Ruby
0x10ae95000 - 0x10ae96fff +ext.bundle (0) /Users/USER/*/ext.bundle
0x10af49000 - 0x10af49fff wait.bundle (83.4) <6A6ADDD7-3A00-3C21-AA4B-8EEAA083C65F> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin12.0/io/wait.bundle
0x7fff6a722000 - 0x7fff6a75693f dyld (210.2.3) /usr/lib/dyld
0x7fff86209000 - 0x7fff86217ff7 libsystem_network.dylib (77.10) <0D99F24E-56FE-380F-B81B-4A4C630EE587> /usr/lib/system/libsystem_network.dylib
0x7fff875b9000 - 0x7fff87605ff7 libauto.dylib (185.1) <73CDC482-16E3-3FC7-9BB4-FBA2DA44DBC2> /usr/lib/libauto.dylib
0x7fff8778f000 - 0x7fff877deff7 libcorecrypto.dylib (106) <57BC99C6-3C3F-344C-BDD6-25E845D956F2> /usr/lib/system/libcorecrypto.dylib
0x7fff87b76000 - 0x7fff87b7dfff libcopyfile.dylib (89) <876573D0-E907-3566-A108-577EAD1B6182> /usr/lib/system/libcopyfile.dylib
0x7fff87b7e000 - 0x7fff87b83fff libcompiler_rt.dylib (30) <08F8731D-5961-39F1-AD00-4590321D24A9> /usr/lib/system/libcompiler_rt.dylib
0x7fff8912a000 - 0x7fff8912cfff libquarantine.dylib (52) <4BE2E642-A14F-340A-B482-5BD2AEFD9C24> /usr/lib/system/libquarantine.dylib
0x7fff89185000 - 0x7fff891a9ff7 libc++abi.dylib (24.2) <340E7C7B-DC93-3AA2-B015-B1C9541EC255> /usr/lib/libc++abi.dylib
0x7fff89965000 - 0x7fff8999dfff libncurses.5.4.dylib (37.3) <68D5B5F5-8252-3F1E-AFF1-C6AFE145DBC1> /usr/lib/libncurses.5.4.dylib
0x7fff89c6f000 - 0x7fff89c70ff7 libdnsinfo.dylib (453.16) <38A3E0F4-E34C-3D45-A2C9-4CDE2DF007BD> /usr/lib/system/libdnsinfo.dylib
0x7fff89c91000 - 0x7fff89da9a27 libobjc.A.dylib (532) <9FA80CDA-97F4-3801-8879-0C1B976BC5CA> /usr/lib/libobjc.A.dylib
0x7fff8a46a000 - 0x7fff8a46dff7 libdyld.dylib (210.2.3) /usr/lib/system/libdyld.dylib
0x7fff8a8b2000 - 0x7fff8a8e0ff7 libsystem_m.dylib (3022.6) /usr/lib/system/libsystem_m.dylib
0x7fff8b327000 - 0x7fff8b327fff libkeymgr.dylib (25) /usr/lib/system/libkeymgr.dylib
0x7fff8b377000 - 0x7fff8b378ff7 libsystem_sandbox.dylib (220) <3C3B03CF-C525-3CB3-8557-62E91B93AC95> /usr/lib/system/libsystem_sandbox.dylib
0x7fff8bfb7000 - 0x7fff8bfccff7 libdispatch.dylib (228.18) <0B6B6E7F-4D8A-3F3B-A4BF-6CF34638DBBB> /usr/lib/system/libdispatch.dylib
0x7fff8bfcd000 - 0x7fff8c099fef libsystem_c.dylib (825.24) <16B6B86C-53EE-36E8-AC2B-4AADC1008098> /usr/lib/system/libsystem_c.dylib
0x7fff8c09a000 - 0x7fff8c09bfff libsystem_blocks.dylib (59) /usr/lib/system/libsystem_blocks.dylib
0x7fff8c328000 - 0x7fff8c329ff7 libSystem.B.dylib (169.3) <132FE02E-3865-3F1F-B78D-C93D65930A67> /usr/lib/libSystem.B.dylib
0x7fff8d2b4000 - 0x7fff8d2bffff libsystem_notify.dylib (98.5) /usr/lib/system/libsystem_notify.dylib
0x7fff8dd67000 - 0x7fff8dd6fff7 libsystem_dnssd.dylib (379.27.1) /usr/lib/system/libsystem_dnssd.dylib
0x7fff8ddf5000 - 0x7fff8de03fff libcommonCrypto.dylib (60026) <2D6537F5-1B5E-305C-A1CF-D1FA80CA3939> /usr/lib/system/libcommonCrypto.dylib
0x7fff8e370000 - 0x7fff8e392ff7 libxpc.dylib (140.37) /usr/lib/system/libxpc.dylib
0x7fff8ed00000 - 0x7fff8ed02ff7 libunc.dylib (25) <92805328-CD36-34FF-9436-571AB0485072> /usr/lib/system/libunc.dylib
0x7fff8ed08000 - 0x7fff8ed0eff7 libunwind.dylib (35.1) <21703D36-2DAB-3D8B-8442-EAAB23C060D3> /usr/lib/system/libunwind.dylib
0x7fff8f379000 - 0x7fff8f381fff liblaunch.dylib (442.21) <224CB010-6CF8-3FC2-885C-6F80330321EB> /usr/lib/system/liblaunch.dylib
0x7fff8ff56000 - 0x7fff9004bfff libiconv.2.dylib (34) /usr/lib/libiconv.2.dylib
0x7fff91fd3000 - 0x7fff9203bff7 libc++.1.dylib (65.1) <20E31B90-19B9-3C2A-A9EB-474E08F9FE05> /usr/lib/libc++.1.dylib
0x7fff9209f000 - 0x7fff920a4fff libcache.dylib (57) <65187C6E-3FBF-3EB8-A1AA-389445E2984D> /usr/lib/system/libcache.dylib
0x7fff920b2000 - 0x7fff920b3ff7 libremovefile.dylib (23.1) /usr/lib/system/libremovefile.dylib
0x7fff920b4000 - 0x7fff920cfff7 libsystem_kernel.dylib (2050.9.2) /usr/lib/system/libsystem_kernel.dylib
0x7fff9212c000 - 0x7fff92162fff libsystem_info.dylib (406.17) <4FFCA242-7F04-365F-87A6-D4EFB89503C1> /usr/lib/system/libsystem_info.dylib
0x7fff92163000 - 0x7fff92169fff libmacho.dylib (829) /usr/lib/system/libmacho.dylib

External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 91787
thread_create: 15
thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=60.7M resident=26.6M(44%) swapped_out_or_unallocated=34.1M(56%)
Writable regions: Total=22.0M written=2664K(12%) resident=4900K(22%) swapped_out=0K(0%) unallocated=17.2M(78%)

REGION TYPE VIRTUAL
=========== =======
MALLOC 13.4M
MALLOC guard page 32K
MALLOC_LARGE (reserved) 128K reserved VM address space (unallocated)
STACK GUARD 56.0M
Stack 8192K
VM_ALLOCATE 4K
__DATA 924K
__LINKEDIT 52.9M
__TEXT 8008K
shared memory 12K
=========== =======
TOTAL 139.2M
TOTAL, minus reserved VM space 139.1M

After triggering Lusty Juggler, Supertab stops working - pressing Tab inserts "<Plug>SuperTabForward". I suspect this is blameable on the known Vim bug of maparg() not returning flags.

:imap <Tab>

i <Tab> <Plug>SuperTabForward

but AFTER triggering LustyJuggler it returns:

i <Tab> * <Plug>SuperTabForward

My workaround:

--- plugin/lusty-juggler.vim    2011-04-08 00:23:59.000000000 +0200
+++ plugin/lusty-juggler.vim    2011-04-17 14:29:04.000000000 +0200
@@ -557,7 +557,9 @@
       end
       # Can't use '<CR>' as an argument to :call func for some reason.
       map_key("<CR>", ":call <SID>LustyJugglerKeyPressed('ENTER')<CR>")
-      map_key("<Tab>", ":call <SID>LustyJugglerKeyPressed('TAB')<CR>")
+      
+      # From Richard Laffers: I commented this out to prevent breaking of Supertab
+      #map_key("<Tab>", ":call <SID>LustyJugglerKeyPressed('TAB')<CR>")
 
       # Cancel keys.
       map_key("i", ":call <SID>LustyJugglerCancel()<CR>")
@@ -599,7 +601,9 @@
         unmap_key(c)
       end
       unmap_key("<CR>")
-      unmap_key("<Tab>")
+
+      # From Richard Laffers: I commented this out to prevent breaking of Supertab
+      #unmap_key("<Tab>")
 
       unmap_key("i")
       unmap_key("q")

Btw, thanks for this plugin, it's gold.

This is a request to divide up the lusty repository into multiple separate smaller repositories, one repository per plugin. I recognize this is a big request, but I think it will be helpful giving the shift in the landscape of Vim plugins, and specifically Vim plugin management.

The trend to install plugins now is through a plugin manager. Popular examples include Pathogen, Vundle, and vim-addon-manager. These plugin managers will fetch plugin code from VCS repositories (especially GitHub) where possible, and from the Vim Scripts website when no VCS repository available.

The lusty repository hosts two separate scripts: LustyExplorer and LustyJuggler. When a user of one of these Vim plugin managers requests one of the plugins, they actually get both of the lusty plugins installed, whether they wanted both or not.

I suppose both of these plugins are in the same repository because they rely on a common library of shared code. What I'm proposing then is splitting the sjbach/lusty repository into three separate repositories:

• sjbach/LustyJuggler: the LustyJuggler code
• sjbach/LustyExplorer: the LustyExplorer code
• sjbach/LustyCommon: the common library of code for the two lusty plugins; this will need to be released as a separate Vim script and marked as a dependency for LustyJuggler and LustyExplorer

Because the code in the repository is not well segregated, I'm not sure if it would be possible to keep all the revision history using a tool like git-filter-branch The possible loss of this information has to be weighed against the advantages in supporting the new plugin management systems.

so the bar should display:
[a]Readme | [s]ext.c | [d] spore.rb
and alternatively
[1]Readme | [2]ext.c | [3] spore.rb

so don't need to count the buffers ;)

Hi!

I ran into this issue: https://wincent.com/issues/1617

Could you do some workaround for this?

It currently breaks this plugin to work on my 32bit system.

Hi,

With lates vim (from hg) when I try to open a folder, the vim crashes. If add a trailing slash to the directory name it works:

$ vim src/
..editing here, it works now
$

But without the trailing slash:
~$ vim src
Vim: Caught deadly signal SEGV

Vim: Finished.
zsh: segmentation fault vim src

I'm using the lates vim from hg, and if I remove lusty explorer from my plugins it works in both formats

I have the latest development version of lusty-juggler installed along side paredit.vim from slimv 0.93. I think there might be some key binding conflicts between the two plugins. The "s" and "d" bindings don't work as expected after I've started lj.

When I press "s", vim changes to insert mode and inserts ":call 17_LustyJugglerKeyPressed('{key}')" whenever any of lj's keybindings are pressed.

When I press "d", vim doesn't do anything, but subsequent presses delete a character in the buffer.

I'm using MacVim 7.3 (Snapshot 61) on OS X. Please let me know if there's anything I can do to help you debug this problem.

Error detected while processing function 33_LustyJugglerKeyPressed:
line 1
E1: No such mapping
E1: No such mapping
E1: No such mapping
...

it actually switches buffers, but this error is really annoying.

I use MacVim snapshot 64 on Lion with vundle.

what it can be connected with?

mkdir ~/test-lusty-bug
cd ~/test-lust-bug

Open vim.

Create two buffers a.txt and b.txt and split horizontally (a.txt open in top 50%, and b.txt open in bottom 50%)

:ls
2 %a "b.txt" line 1
3 a "a.txt" line 0

Press leader and lr to open Lusty Explorer

You'll see that the heights of a.txt and b.txt are not maintained, rather a.txt shrinks to 1 line visible and b.txt now takes whole view (minus lusty window at bottom). Cancelling returns to normal but this is an annoyance as I can no longer study most of real estate when opening lustyexplorer.

Hi,

I'm using Vim 7.3 on ArchLinux and I'me getting following error when trying to invoke buffer explorer or buffer grep:

undefined method full_name' for nil:NilClass (eval):362:inblock in compute_buffer_entries'
(eval):361:in each' (eval):361:incompute_buffer_entries'
(eval):592:in run' (eval):1:inblock in

Probably sth with Vim 7.3, as I remember correctly it worked fine in 7.2.

And I also noticed that LustyJuggler doesn't find any open buffers, it always shows "No other buffers".

When I split windows in vim ( s), and call lusty browser, following errors are shown in middle of each vim window:

knotify(1923) NotifyByPopup::slotDBusNotificationClosed: 0 -> 0
knotify(1923) NotifyByPopup::slotDBusNotificationClosed: failed to find knotify id for dbus_id 0

These errors appears randomly, when moving cursor in a window.

I'm using Ubuntu 10.04 LTS, Lusty Explorer 3.1.1 and
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Apr 16 2010 12:40:58)
Included patches: 1-330
Compiled by buildd@
Huge version with GTK2-GNOME GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap
+menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm
-mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte
+multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript
+printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind
+signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white +tcl +terminfo +termresponse
+textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual
+visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup
+X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"

I'm experiencing a bug very similar to #39. Here's how it happens:

1. Switch to a window split using a custom binding (nmap <silent> <C-j> :wincmd j<CR>)
2. Enter insert mode
3. Press escape to exit insert mode
4. The text :call <SNR>59_LustyJugglerCancel() is inserted every time I press escape

I have commented out the line of code that binds escape to LustyJugglerCancel to try to alleviate the problem for now.

I am running Vim 7.3p198 for Windows with Lusty Juggler 1.3.

It's fairly simple to change the key bindings to Dvorak (aoeuidhtns), but it'd be nice if it were a tad easier. In one of the later versions of LJ, the binding 'i' for ":call LustyJugglerCancel()" which interferes a little bit. Commenting that and the unmap for the binding fixes the intersection. I suppose what I'm suggesting is a configuration setting.

Hi.

First things first: thanks a lot for your lusty plugins. Juggler is 99% what I was looking for. It's a very clever way to switch buffers. I still have to get used to explorer, though.

My only issue with both plugins is that they hardcode the key combinations, and they partly intefere with l that I was already using.

I hope that you can fix this somehow. I'm completely new to vimscript, so I don't dare to offer a patch yet.

Hey Stephen,

First of all: great Juggler plugin :)
Would it be very tricky to include a setting like max_buffers that specify which keys get mapped? I ask because I have given my ; key special meaning, and it breaks (it doesn't restore) every time I have run the juggler (since it is the key for the 10th buffer).

Telling the juggler that 9 buffers is enough for me would solve the problem. Another solution would be a setting to not map the home row keys, but instead use the number keys.

How would you stand towards such changes?

Cheers,
Vincent

It'd be really nice to be able to get tags as one of the lusty options. I started to work on this but I'm not really sure where to go from here. It seems like it should be fairly easy but I'm not sure how to get to the tags within the ruby code.

Hello,

A change introduced in version 2.2.0 prevents Lusty Explorer from operating properly under Cygwin on Windows XP. The error message follows (error message is from version 2.2.2):

Error detected while processing ~/.vim/plugin/lusty-explorer.vim:
line 1533:
LoadError: (eval):1:in `require': no such file to load -- io/wait

Hi,
when a ack search result window is opened if you call (eg.) <Leader>lj you get this:

NULL pointer given
(eval):570:in `evaluate'
(eval):570:in `eva'
(eval):507:in `buf_name'
(eval):476:in `names'
(eval):476:in `collect'
(eval):476:in `names'
(eval):316:in `create_items'
(eval):299:in `print'
(eval):157:in `print_buffer_list'
(eval):100:in `run'
(eval):369
(eval):599:in `protect'
(eval):369

Is it a lusty problem?

I'm experiencing weird issues with LustyExplorer that give me errors like the following

stack level too deep
(eval):2021:in `push'
(eval):4
(eval):252:in `profile'
(eval):4

I get that one when I do <Leader>vrc, which is a mapping in my .vimrc defined as

:nnoremap <Leader>vrc :e $MYVIMRC<CR>

Sometimes when quitting a file I will get a shorter error message of "stack level too deep"

If I move lusty-explorer.vim to lusty-explorer.vim.bak, the issue disappears.

I can also get these errors by opening the explorer and repeatedly pressing the left and right keys:

stack level too deep
(eval):517:in `key_pressed'
(eval):842:in `key_pressed'
(eval):4
(eval):252:in `profile'
(eval):4

I have a perplexing bug. Since upgrading to Ubuntu 11.04 Natty Narwhal on one machine, my work desktop, LustyJuggler always complains "No other buffers" when I enter <LEADER>lj, even when I am editing multiple files, and :buffers lists multiple open buffers. I do not experience this bug on my laptop.

The only ideas I have are that LustyJuggler never starts running (@running is always false) or that $lj_buffer_stack never gets any new elements pushed on to it, even when opening new files.

I don't understand why this no longer works on my desktop but does on my laptop. The desktop is 32-bit Ubuntu while the laptop is 64-bit but I don't think that's relevant. They both claim to have Ruby-enabled Vim. Running :echo eval(has("ruby")) returns 1. I don't know how to get LustyJuggler to be more verbose (e.g., dump the contents of $lj_buffer_stack). If you have any insight, I'd love the help. It's very annoying to lose one of my favorite plugins.

I have also tried removing my $HOME/.vim and $HOME/.vimrc files and adding the plugin fresh. Still the same issue.

I found that LustyExplorer seems to cache filenames. So if i create a file in another window it doesn't find it. There should be a refresh option.

I have been using delimitMate for quite sometime. Recently I found about lusty juggler and I find it really easy to get most recently used buffers and switch between them. So I started using lusty juggler and found strange issues with delimitMate.

I reported them to delimitMate maintainer and he said, "The problem is that lusty-juggler changes the mapping for its own use and then tries to restore the previous mapping, but that's not reliable and causes problems because lusty-juggler uses :inoremap and delimitMate needs :imap in those cases."

For reference you can see: Raimondi/delimitMate#62

I haven't been able to get time out to look into myself and submit the fix, so I thought I should report here so someone might be able to get it fixed before me and everyone can benefit. I wonder if there are other users who use lusty with delimitMate.

Sometime, when I open File Explorer:

(eval):396: [BUG] rb_gc_mark(): unknown data type 0x14(0xa3dd858) corrupted object
ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux]

-- control frame ----------
c:0013 p:---- s:0044 b:0044 l:000043 d:000043 CFUNC :to_s
c:0012 p:0031 s:0042 b:0035 l:000026 d:000034 BLOCK (eval):396
c:0011 p:---- s:0032 b:0032 l:000031 d:000031 FINISH
c:0010 p:---- s:0030 b:0030 l:000029 d:000029 CFUNC :each_byte
c:0009 p:0063 s:0027 b:0027 l:000026 d:000026 METHOD (eval):395
c:0008 p:0101 s:0021 b:0021 l:000020 d:000020 METHOD (eval):301
c:0007 p:0044 s:0018 b:0018 l:000017 d:000017 METHOD (eval):644
c:0006 p:0047 s:0015 b:0015 l:000014 d:000014 METHOD (eval):660
c:0005 p:0010 s:0012 b:0012 l:002174 d:000011 BLOCK (eval):1
c:0004 p:0093 s:0010 b:0010 l:000009 d:000009 METHOD (eval):173
c:0003 p:0015 s:0006 b:0006 l:002174 d:000005 EVAL (eval):1
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH

c:0001 p:0000 s:0002 b:0002 l:002174 d:002174 TOP

-- Ruby level backtrace information ----------------------------------------
(eval):1:in <main>' (eval):173:inprofile'
(eval):1:in block in <main>' (eval):660:inrun_from_wd'
(eval):644:in run' (eval):301:inrun'
(eval):395:in create_explorer_window' (eval):395:ineach_byte'
(eval):396:in block in create_explorer_window' (eval):396:into_s'

-- C level backtrace information -------------------------------------------
/usr/lib/libruby.so.1.9(rb_vm_bugreport+0x72) [0xb6dbbfb2]
/usr/lib/libruby.so.1.9(+0x51b31) [0xb6cb1b31]
/usr/lib/libruby.so.1.9(rb_bug+0x3a) [0xb6cb213a]
/usr/lib/libruby.so.1.9(+0x673ed) [0xb6cc73ed]
/usr/lib/libruby.so.1.9(+0x677ba) [0xb6cc77ba]
/usr/lib/libruby.so.1.9(st_foreach+0xc3) [0xb6d5fe03]
/usr/lib/libruby.so.1.9(+0x65208) [0xb6cc5208]
/usr/lib/libruby.so.1.9(+0x66f48) [0xb6cc6f48]
/usr/lib/libruby.so.1.9(+0x68684) [0xb6cc8684]
/usr/lib/libruby.so.1.9(rb_newobj+0x4f) [0xb6cc8e8f]
/usr/lib/libruby.so.1.9(+0x1033aa) [0xb6d633aa]
/usr/lib/libruby.so.1.9(rb_str_new_cstr+0x32) [0xb6d65232]
/usr/lib/libruby.so.1.9(rb_usascii_str_new_cstr+0x22) [0xb6d65282]
/usr/lib/libruby.so.1.9(rb_fix2str+0x6b) [0xb6cf7eab]
/usr/lib/libruby.so.1.9(+0x97f3d) [0xb6cf7f3d]
/usr/lib/libruby.so.1.9(+0x146f48) [0xb6da6f48]
/usr/lib/libruby.so.1.9(+0x152723) [0xb6db2723]
/usr/lib/libruby.so.1.9(rb_funcall+0x20d) [0xb6db2e9d]
/usr/lib/libruby.so.1.9(rb_obj_as_string+0x8a) [0xb6d6771a]
/usr/lib/libruby.so.1.9(+0x14a2e9) [0xb6daa2e9]
/usr/lib/libruby.so.1.9(+0x151033) [0xb6db1033]
/usr/lib/libruby.so.1.9(+0x151cd4) [0xb6db1cd4]
/usr/lib/libruby.so.1.9(rb_yield+0x56) [0xb6db7ae6]
/usr/lib/libruby.so.1.9(+0x1026d0) [0xb6d626d0]
/usr/lib/libruby.so.1.9(+0x146f2d) [0xb6da6f2d]
/usr/lib/libruby.so.1.9(+0x155c6a) [0xb6db5c6a]
/usr/lib/libruby.so.1.9(+0x14ad34) [0xb6daad34]
/usr/lib/libruby.so.1.9(+0x151033) [0xb6db1033]
/usr/lib/libruby.so.1.9(+0x15142c) [0xb6db142c]
/usr/lib/libruby.so.1.9(rb_eval_string+0x51) [0xb6db89e1]
/usr/lib/libruby.so.1.9(rb_protect+0x140) [0xb6cb6740]
/usr/lib/libruby.so.1.9(rb_eval_string_protect+0x2e) [0xb6da8cfe]
gvim(ex_ruby+0x79) [0x81e9c29]
gvim(do_cmdline+0x1164) [0x80c48b4]
gvim() [0x809e407]
gvim() [0x809eb22]
gvim() [0x80a26ac]
gvim(ex_call+0x1dd) [0x80a549d]
gvim(do_cmdline+0x1164) [0x80c48b4]
gvim() [0x80c7920]
gvim(do_cmdline+0x38f1) [0x80c7041]
gvim() [0x8135fb0]
gvim(normal_cmd+0x6fd) [0x813d77d]
gvim(main_loop+0x3a8) [0x80fbdd8]
gvim(main+0x1575) [0x80fdcb5]
/lib/libc.so.6(__libc_start_main+0xe6) [0xb6f96c76]
gvim() [0x806fdb1]

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

Vim: Получен убийственный сигнал ABRT
Vim: Готово.

vim --version

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Sep 4 2010 16:28:01)
Заплатки: 1-3
Скомпилирован ArchLinux
Большая версия с графическим интерфейсом GTK2. Включённые (+) и отключённые (-) особенности:
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff
+digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi
+file_in_path +find_in_path +float +folding -footer +fork() +gettext
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
+linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
+mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm
-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg
-osfiletype +path_extra +perl +persistent_undo +postscript +printer -profile
+python -python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim
+xsmp_interact +xterm_clipboard -xterm_save
общесистемный файл vimrc: "/etc/vimrc"
пользовательский файл vimrc: "$HOME/.vimrc"
пользовательский файл exrc: "$HOME/.exrc"
общесистемный файл gvimrc: "/etc/gvimrc"
пользовательский файл gvimrc: "$HOME/.gvimrc"
общесистемный файл меню: "
$VIMRUNTIME/menu.vim"
значение $VIM по умолчанию: "/usr/share/vim"
Параметры компиляции: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -march=i686 -mtune=generic -O2 -pipe -D_FORTIFY_SOURCE=1 -I/usr/include/ruby-1.9.1 -I/usr/include/ruby-1.9.1/i686-linux -DRUBY_VERSION=19
Сборка: gcc -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/local/lib -o vim -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lXt -lncurses -lacl -lgpm -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -fstack-protector -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lutil -lc -L/usr/lib/python2.6/config -lpython2.6 -lutil -Xlinker -export-dynamic -lruby -lrt -lm

After updating to Mountain Lion, I get following error using Lusty on MacVim:

bignum too big to convert into long' (eval):1665:inheight='
(eval):1665:in max_height' (eval):1683:incompute_optimal_layout'
(eval):1625:in print' (eval):610:inrefresh'
(eval):499:in run' (eval):793:inrun'
(eval):805:in run_from_path' (eval):4 (eval):252:inprofile'
(eval):4

Changing the constant to 2^(16-1)-2 fixes the problem.

See http://code.google.com/p/macvim/issues/detail?id=420.

After deleting a buffer with :bd I can still see it between the ones
displayed with Lusty Juggler.

pressing , etc in insert mode sometimes causes
:call 41_LustyJugglerCancel()
to be inserted into my document
using macvim latest.
It seems it tries to execute a command while in insert mode which is incorrect

I've installed lusty-explorer.vim V2.1.0 and get the following error
when trying to open a file:

Error detected while processing /Users/charl/.vim/plugin/lusty-explorer.vim:

line 1460:
TypeError: can't modify frozen string

I get this from vim (v7.2.182) and macvim (v7.2.148) on my MacBook Pro.

Any ideas?