Re: Compiling Vim
fREW wrote: Hey Tony, What is the URL for your Vim Compile site? I can't find the link anywhere. Thanks! -fREW Method I: Start at my home portal http://users.skynet.be/antoine.mechelynck/ Click "The Vim Editor" then the two bottom links in the list at top left point to my HowTo pages for Windows and Unix/Linux. This method can easily be deduced from my email address plus the knowledge of how Belgacom/Skynet user sites are named. Method II: Direct links: Windows: http://users.skynet.be/antoine.mechelynck/vim/compile.htm Unix:http://users.skynet.be/antoine.mechelynck/vim/compunix.htm Best regards, Tony. -- ROMEO: Courage, man; the hurt cannot be much. MERCUTIO: No, 'tis not so deep as a well, nor so wide as a church- door; but 'tis enough, 'twill serve.
Bug in completion
Hi All, I see the following bug: 1. Open Vim, and vertically split into two windows. 2. File name complete something with very long file names (longer than the width of the window you're typing into). The screen is "hodge podge". There are uncleared pieces of the completion menu left on the screen (on top of the other buffer). I'm using Vim 7.1a (sorry, haven't tested with 7.1b yet). GI -- 'Selfishness' -- Not being considerate of other people's selfishness.
RE: MSVC build option about default library MSVCRT
Bram is wise. Adding a nodefaultlib:msvcrt could potentially break things if you set USE_MSVCRT=1 to use the CRT DLL instead of statically linking the CRT. The problem is that you're linking a static-CRT version of Vim with DLL-CRT versions of ActiveState components. The problem is not with Vim's makefile. Generally, if you have lib conflicts, it means you've done something wrong. In this case, you have one OBJ that was compiled for use with the static CRT, and another OBJ that was compiled for use with the dynamically-linked CRT. Each of them tell the linker "you should probably link me with this particular CRT". Luckily, the linker is smart enough to only allow one CRT at a time. For a standalone program, statically linking with the CRT is generally the way to go, so Vim defaults to doing this. Using the CRT DLL saves about 150k in disk space, but the CRT DLL is 400-800k, depending on which version of Visual C++ you're using. The CRT is potentially already in memory in another process, so this may or may not save memory at runtime. For a program that interacts with other DLLs (such as loading Perl, Python, Ruby, etc. DLLs at runtime), the CRT DLL starts to make more sense. In addition to saving disk space (one CRT DLL instead of 150k of static CRT in each executable), you save memory (one CRT DLL loaded, and all modules share the same heap) and in some cases you avoid bugs (only one CRT so you don't have conflicting CRT settings like locale). However, you now have to redistribute the CRT with your product, and starting with VC 8.0, you have to get the CRT's manifest correctly embedded into your EXE and DLLs. -Original Message- From: Yongwei Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 7:54 PM To: Bram Moolenaar Cc: Vim-dev mailing list Subject: Re: MSVC build option about default library MSVCRT Hi Bram, On 15/05/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > [redirecting to vim-dev] > > > I am wondering whether l. 705 of Make_mvc.mak in vim-7.1-extra.tar.gz > > should be change from > > > > LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc > > > > to > > > > LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc /nodefaultlib:msvcrt > > > > I have been using it for maybe half a year and not found a single > > problem yet. It will eliminate this message when building vim.exe: > > > > libcmt.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib' > > conflicts with use of other libs; use /NODEFAULTLIB:library > > > > Without /nodefaultlib:msvcrt vim.exe will have a dependency on > > MSVCR71.DLL (I use MSVC 7.1). This added flag will not affect > > gvim.exe. The command lines I used are: > > > > nmake -f Make_mvc.mak GUI=yes OLE=yes MBYTE=yes IME=yes GIME=yes > > CSCOPE=yes PERL=C:\Perl DYNAMIC_PERL=yes PERL_VER=58 > > PYTHON=C:\Python24 DYNAMIC_PYTHON=yes PYTHON_VER=24 RUBY=C:\ruby > > DYNAMIC_RUBY=yes RUBY_VER=18 RUBY_VER_LONG=1.8 TCL=C:\Tcl > > DYNAMIC_TCL=yes TCL_VER=84 TCL_VER_LONG=8.4 XPM=C:\xpm %* > > nmake -f Make_mvc.mak MBYTE=yes CSCOPE=yes PERL=C:\Perl > > DYNAMIC_PERL=yes PERL_VER=58 PYTHON=C:\Python24 DYNAMIC_PYTHON=yes > > PYTHON_VER=24 RUBY=C:\ruby DYNAMIC_RUBY=yes RUBY_VER=18 > > RUBY_VER_LONG=1.8 TCL=C:\Tcl DYNAMIC_TCL=yes TCL_VER=84 > > TCL_VER_LONG=8.4 XPM=C:\xpm %* > > I'm very careful with these things. Make_mvc.mak is used for several > versions of MSVC, starting at 4.1. You need to check all versions to > make sure it doesn't cause any problems. Er ... I do not have access to such old versions. I work on 7.1, and can do so on 6.0 too. However, I believe MSVC versions are not significant here. See below. > I suppose the error message you get is from some of the languages > Ruby/Python/Tcl/ I don't get it, thus you can probably solve it by > checking your included libraries. Perhaps one has not been build by > MSVC? That usually causes trouble (not just an error message, but a > crash at runtime). Try actually using all the languages. I noticed that you did not build vim.exe with the languages, which should be the reason you do not see the warning message. I have verified that removing ActiveTcl 8.4 from my build makes /nodefaultlib:msvcrt not necessary: in fact, then the option does not have any effect at all. I did actually try executing simple commands in Perl, Python, Tcl, and Ruby, and they all succeeded. I use the popular ActiveState builds for Perl, Python, and Tcl, and ruby185-21 from the Ruby web site. I believe they are all MSVC compatible. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Three small patches
Hi, I wanted to send this several days ago, but the lists kept rejecting my mails (silently). Took me a while to figure out that my mail client started send mails from @gmx.net instead of @gmx.de. Hi, here are some low-risk patches to improve the mac experience of vim 7.1. I hope they can be included before the release :-) contextmenu1.diff, contextmenu2.diff: On intel macs, the context menu doesn't work, because the test if the system provides context menus is not endian-agnostic. Version 1 of this patch fixes the test. Version 2 removes the test altogether, since all versions of OS X support context menus. Version 2 does also remove a call to a deprecated function (InitContextualMenus()). I believe these checks are from before Apple used ppc chips...I'd suggest including version 2. doc.diff: Two tiny documentation fixes. dimscrollbars.diff: When a window does not belong to the active application, its controls should be deactivated (dimmed). Normally, the standard event handler does this for free, but mac vim does (not yet) use the standard event handler, so this patch does it manually. Note that the tab drawer _does_ use the standard event handler, so without this patch the drawer's scrollbar is dimmed while the main scrollbar(s) are not when vim is not active, which looks kinda weird. Bye, Nico contextmenu1.diff Description: Binary data contextmenu2.diff Description: Binary data dimscrollbars.diff Description: Binary data doc.diff Description: Binary data
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Stephan Hegel wrote: A.J.Mechelynck wrote: patch -p0 As long as you have two patches this can be done easily. But what if you have 100+ ? Then try this: cat patches/7.1.* > patchfile patch -p0 < patchfile rm patchfile Done. Rgds, Stephan. If you have more than a hundred, Bram sets up recapitulative patches for one hundred patchlevels at a time, so if you want to patch plain-vanilla 7.0 to compile 7.0.233 you would do gunzip -c patches/7.0.001-100.gz |patch -p0 gunzip -c patches/7.0.101-200.gz |patch -p0 patch -p0 With command-line editing, you can recall the latest command and change only the last (or the last two) digit(s) every time. But normally you would download and implement the patches a few at a time as they are published, and there would never be many of them at any one time, except maybe the first time you compile Vim; so now (that there aren't many patches to the latest version) is a good time to start. - Using "cat" is OK as long as you can be sure that you'll get them in numeric order: this is usually the case on Unix but not necessarily on Dos, where a wildcarded filename usually gets its results in directory order, not sorted by filename. - By patching individually, if one of the patches fails horribly you may decide not to try the following. - Usually there aren't more than a handful of _new_ patches anyway, so (except when starting from scratch with many patches already published) it's hardly worth the trouble going to a cat step. Best regards, Tony. -- Justice, n.: A decision in your favor.
motion [/ bug
Hello all:
I am observing wierd problem with the motion [/, i.e. goto previous
start of
C comment motion. Please see the 'C' source pasted below as a test
case.
#include
int main() {
char *str = "rm -rf /tmp/foo/*";
/* this is comment */
int position = 0;
}
When I position the cursor on the variable 'position' and execute the
[/ motion,
the cursor moves to foo/* which is actually part of a string. It should
have
moved to the beginning of the comment. I believe that the motion
ignores C
semantics and does a pure textual search to find the most proper start
of a
comment. It don't know if this is a bug or a feature. I have observed
this
behaviour with both 6.4 and the latest 7.0 versions of vim. I even
tested it
with ':set compatible', same problem. Would appreciate any suggestions
to
overcome the problem.
My vim config is described below:
VIM - Vi IMproved 7.0 (2006 May 7, compiled May 3 2007 05:10:32)
Included patches: 1, 3-4, 7-9, 11, 13-17, 19-26, 29-31, 34-44, 47,
50-56, 58-64, 66-73, 75, 77-92, 94-107, 109-129, 131, 133-137, 139-155,
157-160, 162-169, 172-179, 181-196, 199-207, 209-214, 216-231, 234-235
Modified by <[EMAIL PROTECTED]>
Compiled by <[EMAIL PROTECTED]>
Huge 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
+cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path
+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_xterm +multi_byte +multi_lang
-mzscheme
-netbeans_intg -osfiletype +path_extra +perl +postscript +printer
+profile
+python +quickfix +reltime +rightleft -ruby +scrollbind +signs
+smartindent
-sniff +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: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2-D_REENTRANT
-D_GNU_SOURCE -Wdeclaration-after-statement -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
-I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE
-I/usr/include/python2.4 -pthread
Linking: gcc -Wl,-E
-Wl,-rpath,/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE
-L/usr/local/lib -o vim -lselinux -lncurses -lacl -lgpm -Wl,-E
-Wl,-rpath,/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE -lperl -lresolv
-lutil -lc -L/usr/lib64/python2.4/config -lpython2.4 -lutil -lm
-Xlinker -export-dynamic
Need
a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
Re: new text object feature request
--- "Larson, David" <[EMAIL PROTECTED]> wrote: > I often need to replace parameter text and usually try to remember the > text object that selects the "inner parameter", only to come up short > since that type isn't defined. It seems natural to have a "parameter" > text object, where it would act on the text between commas or > parentheses, i.e. from "(," to ",)". > > What say you? Something worthy of the todo list? Hello, I believe that can be done using Vimscript, so you could try that first. regards, Peter ___ How would you spend $50,000 to create a more sustainable environment in Australia? Go to Yahoo!7 Answers and share your idea. http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html
Re: MSVC build option about default library MSVCRT
Hi Bram, On 15/05/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: [redirecting to vim-dev] > I am wondering whether l. 705 of Make_mvc.mak in vim-7.1-extra.tar.gz > should be change from > > LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc > > to > > LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc /nodefaultlib:msvcrt > > I have been using it for maybe half a year and not found a single > problem yet. It will eliminate this message when building vim.exe: > > libcmt.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib' > conflicts with use of other libs; use /NODEFAULTLIB:library > > Without /nodefaultlib:msvcrt vim.exe will have a dependency on > MSVCR71.DLL (I use MSVC 7.1). This added flag will not affect > gvim.exe. The command lines I used are: > > nmake -f Make_mvc.mak GUI=yes OLE=yes MBYTE=yes IME=yes GIME=yes > CSCOPE=yes PERL=C:\Perl DYNAMIC_PERL=yes PERL_VER=58 > PYTHON=C:\Python24 DYNAMIC_PYTHON=yes PYTHON_VER=24 RUBY=C:\ruby > DYNAMIC_RUBY=yes RUBY_VER=18 RUBY_VER_LONG=1.8 TCL=C:\Tcl > DYNAMIC_TCL=yes TCL_VER=84 TCL_VER_LONG=8.4 XPM=C:\xpm %* > nmake -f Make_mvc.mak MBYTE=yes CSCOPE=yes PERL=C:\Perl > DYNAMIC_PERL=yes PERL_VER=58 PYTHON=C:\Python24 DYNAMIC_PYTHON=yes > PYTHON_VER=24 RUBY=C:\ruby DYNAMIC_RUBY=yes RUBY_VER=18 > RUBY_VER_LONG=1.8 TCL=C:\Tcl DYNAMIC_TCL=yes TCL_VER=84 > TCL_VER_LONG=8.4 XPM=C:\xpm %* I'm very careful with these things. Make_mvc.mak is used for several versions of MSVC, starting at 4.1. You need to check all versions to make sure it doesn't cause any problems. Er ... I do not have access to such old versions. I work on 7.1, and can do so on 6.0 too. However, I believe MSVC versions are not significant here. See below. I suppose the error message you get is from some of the languages Ruby/Python/Tcl/ I don't get it, thus you can probably solve it by checking your included libraries. Perhaps one has not been build by MSVC? That usually causes trouble (not just an error message, but a crash at runtime). Try actually using all the languages. I noticed that you did not build vim.exe with the languages, which should be the reason you do not see the warning message. I have verified that removing ActiveTcl 8.4 from my build makes /nodefaultlib:msvcrt not necessary: in fact, then the option does not have any effect at all. I did actually try executing simple commands in Perl, Python, Tcl, and Ruby, and they all succeeded. I use the popular ActiveState builds for Perl, Python, and Tcl, and ruby185-21 from the Ruby web site. I believe they are all MSVC compatible. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: paste clipboard as visual block mode
On 5/16/07, Ernie Rael <[EMAIL PROTECTED]> wrote:
For jvi, not vim, I want to implement a way to "p" the clipboard as
though it were yank'd in block mode. I couldn't see anyway in the vim
doc to do this so I'm guessing that this is not supported. This could be
used to paste a rectangular selection from windows. Also, until I figure
out how to get at the vim specific info in the clipboard, it provides a
workaround for jvi.
If its possible that this might be a feature that vim would want some
day, I'd like to implement it in a compatible way. My first thought was
to use "#p to put the clipboard as block mode, the # has a block mode
flavor to it, but that's taken.
I understand exactly nothing of what you're trying to do, but here's a
function to does what "p" with a block does:
function! PasteRegion()
let [_, lnum, col, _] = getpos('.')
let saved_lnum = lnum
for line in split(getreg(), '\n', 1)
if lnum == line('$')
if append(lnum, "") == 1
throw 'Cannot append line to buffer while pasting region'
endif
endif
let current_line = getline(lnum)
let len = strlen(current_line)
if len < col
let new_line = current_line . repeat(' ', col - len) . line
else
let new_line = strpart(current_line, 0, col) . line .
strpart(current_line, col)
endif
if setline(lnum, new_line) == 1
throw 'Cannot update line ' . lnum
endif
let lnum += 1
endfor
call cursor(saved_lnum, col + 1)
endfunction
This doesn't depend on any internal state of Vim.
Bram: Now that we have exceptions, wouldn't it make sense for append()
to throw an exception when it can't allocate memory? Also, what's
with the C-style error codes for append() and setline()? It's very
unintuitive, especially when there's really no other error code than
failure (1). Too late to change, though.
nikolai
[Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Forward to vim-dev list. See my comments at bottom.
Original Message
Subject: Re: compiling vim7.1 (huge version) gets build with normal version
Date: Tue, 15 May 2007 08:14:28 -0700
From: Tushar Desai <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: A.J.Mechelynck <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
HI Tony,
I tried what you suggested, but now I'm getting this really weird
compile error (I'm compiling on ubuntu 7.04 with gnome 2.0)
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-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/freetype2 -I/usr/include/libpng12 -DORBIT2=1 -pthread
-I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/libart-2.0 -I/usr/include/gconf/2
-I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0
-I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1
-I/usr/include/orbit-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0
-I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12
-I/usr/include/libxml2 -O2 -fno-strength-reduce -Wall
-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl/5.8/CORE -I/usr/include/python2.5 -pthread
-I/usr/include/tcl8.4 -D_REENTRANT=1 -D_THREAD_SAFE=1
-D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/i486-linux -o
objects/gui_gtk.o gui_gtk.c
In file included from /usr/include/glib-2.0/glib/gi18n.h:23,
from /usr/include/libbonobo-2.0/bonobo/bonobo-i18n.h:37,
from /usr/include/libgnome-2.0/libgnome/gnome-i18n.h:41,
from /usr/include/libgnome-2.0/libgnome/libgnome.h:30,
from /usr/include/libgnomeui-2.0/gnome.h:5,
from gui_gtk.c:62:
/usr/include/libintl.h:92: error: expected identifier or '(' before ';' token
make[1]: *** [objects/gui_gtk.o] Error 1
make[1]: Leaving directory `/home/tushar/vim/vim71/src'
make: *** [myself] Error 2
Regards,
-tushar.
- End Original Message -
This may be the problem addressed by patch 7.1.001, see
http://ftp.vim.org/pub/vim/patches/7.1/
So, try the following:
cd ~/vim/vim71
mkdir -pv patches
cd patches
ftp ftp.vim.org
Name: ftp
Password: ftp
cd pub/vim/patches/7.1
mget *
a
bye
cd ..
patch -p0 rsync -avzcP --delete --exclude="/dos/" ftp.nluug.nl::Vim/runtime/ ./runtime/
2>&1 | tee rsync.log
vim -es -u NONE -c '%s/^.*\r//' -cx rsync.log
echo $CONF_OPT_FEAT
(if the reply is not --with-features=huge):
source myconfig
make 2>&1 |tee make.log
etc. If you still get the same error, someone else will have to help you.
Best regards,
Tony.
--
*** NEWSFLASH ***
Russian tanks steamrolling through New Jersey Details at eleven!
paste clipboard as visual block mode
For jvi, not vim, I want to implement a way to "p" the clipboard as though it were yank'd in block mode. I couldn't see anyway in the vim doc to do this so I'm guessing that this is not supported. This could be used to paste a rectangular selection from windows. Also, until I figure out how to get at the vim specific info in the clipboard, it provides a workaround for jvi. If its possible that this might be a feature that vim would want some day, I'd like to implement it in a compatible way. My first thought was to use "#p to put the clipboard as block mode, the # has a block mode flavor to it, but that's taken. -ernie
