Re: filetypedetect for perl6
It has already been included in vim73 branch (on July 30). See: $ hg diff -c c587f56735cc My runtime files were not updated So I mistook that, sorry. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
On Mon, Aug 2, 2010 at 8:49 AM, Nazri Ramliy ayieh...@gmail.com wrote:
On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net wrote:
I have included the recent patches, but not the one that resets
recursive in gen_expand_wildcards(). That is probably causing that
crash.
I noticed that mch_expandpath() is defined on both unix and windows as
unix_expandpath() and dos_expandpath(), respectively. I'll see if it
can be used in place of globpath() (which calls gen_expand_wildcards())
in the function expand_in_path().
If that is successful I'll send a new patch for that and also revert
thechanges
I did in globpath() (skipping url path).
It turned out that using unix_expandpath() for find completion is much,
much slower than using globpath. I ended up using mch_expandpath only when
WIN3264 is defined, and use globpath() otherwise.
The benchmark result (doing a find completion for jingle.gy in the google
chrome source code, the fullname is jingle.gyp):
bench.vim:
8
:set path=~/src/chrome/**
:find jingle.gy
:q
8
Note: there's a single tab character after jingle.gy
Result of running
$ time ./vim-globpath -s bench.vim; time ./vim-mch_expandpath -s bench.vim
for five consecutive runs (whitespaces added to align the timing output below):
./vim-globpath -s bench.vim 0.48s user 1.90s system 92% cpu 2.570 total
./vim-mch_expandpath -s bench.vim 4.26s user 3.97s system 90% cpu 9.135 total
./vim-globpath -s bench.vim 0.53s user 1.64s system 93% cpu 2.310 total
./vim-mch_expandpath -s bench.vim 2.62s user 2.03s system 91% cpu 5.077 total
./vim-globpath -s bench.vim 0.46s user 1.80s system 91% cpu 2.475 total
./vim-mch_expandpath -s bench.vim 3.39s user 3.10s system 86% cpu 7.471 total
./vim-globpath -s bench.vim 0.44s user 1.47s system 88% cpu 2.153 total
./vim-mch_expandpath -s bench.vim 2.00s user 1.92s system 90% cpu 4.350 total
./vim-globpath -s bench.vim 0.47s user 1.46s system 84% cpu 2.271 total
./vim-mch_expandpath -s bench.vim 2.59s user 2.41s system 96% cpu 5.185 total
Based on the benchmark result above it appears that using globpath() is about
4 times faster than using mch_expandpath() for doing find completion.
Attached patch makes find completion works on windows using mch_expandpath().
On unix we still use globpath(). This is done checking #if defined(WIN3264),
I'm not sure if that is the preferred way to detect if we're compiling on
windows.
In the mean time here is the patch to prevent :find tab from crashing on
windows when 'path is set to something like c:\src\**.
With the attached patch the above is no longer necessary.
For people who would like to test this out, please note the remark in :help
'path':
- Careful with '\' characters, type two to get one in the option:
:set path=.,c:\\include
Or just use '/' instead:
:set path=.,c:/include
For example use :set path=.,c:\\include\\** or :set path=.,c:/include/**
to make vim recursively find completion candidates in c:\include directory.
nazri.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
From 9540345bbf11461d7d8723306f1a9b2272e3661d Mon Sep 17 00:00:00 2001
From: nazri ayieh...@gmail.com
Date: Mon, 2 Aug 2010 16:10:56 +0800
Subject: [PATCH] Make find completion work on windows platform
---
src/misc1.c | 78 +++---
1 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/src/misc1.c b/src/misc1.c
index 11c2b1b..8b96b68 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9350,7 +9350,9 @@ expand_path_option(curdir, gap)
STRMOVE(buf + curdir_len, buf + curdir_len + 1);
}
- addfile(gap, buf, EW_NOTFOUND|EW_DIR|EW_FILE);
+ if (ga_grow(gap, 1) == FAIL)
+ return;
+ ((char_u **)gap-ga_data)[gap-ga_len++] = vim_strsave(buf);
}
vim_free(buf);
@@ -9378,8 +9380,11 @@ get_path_cutoff(fname, gap)
{
int j = 0;
- while (fname[j] == path_part[i][j] fname[j] != NUL
- path_part[i][j] != NUL)
+ while ((fname[j] == path_part[i][j]
+#if defined(WIN3264)
+ || vim_ispathsep(fname[j]) vim_ispathsep(path_part[i][j])
+#endif
+ ) fname[j] != NUL path_part[i][j] != NUL)
j++;
if (j maxlen)
{
@@ -9389,8 +9394,15 @@ get_path_cutoff(fname, gap)
}
/* Skip to the file or directory name */
-while (cutoff != NULL vim_ispathsep(*cutoff) *cutoff != NUL)
- mb_ptr_adv(cutoff);
+if (cutoff != NULL)
+ while (
+#if defined(WIN3264)
+ *cutoff == '/'
+#else
+ vim_ispathsep(*cutoff)
+#endif
+ )
+ mb_ptr_adv(cutoff);
return cutoff;
}
@@ -9454,7 +9466,13 @@ uniquefy_paths(gap, pattern)
char_u *dir_end = gettail(path);
len = (int)STRLEN(path);
- while (dir_end path !vim_ispathsep(*dir_end))
+ while (dir_end path
+#if
Re: uninstal.c RegDeleteKeyEx unresolved
John Beckett wrote: A recent change to uninstal.c breaks building Vim on 32-bit Windows. These changes: hg diff -r 573da4dac306:b204ac54bea4 src/uninstal.c involve replacing RegDeleteKey with RegDeleteKeyEx Problem occurs with Windows XP 32-bit, using MS Visual C 6.0, command: nmake -f Make_mvc.mak Build stops at: uninstal.obj : error LNK2001: unresolved external symbol _RegDeleteKeyEx I think RegDeleteKeyEx requires Vista or later, or XP x64. I don't need uninstal, but it breaks the build. I don't think this depends on the OS but on the compiler. I'm building Vim fine on Windows XP. That is with MSVC 2010. We could solve this with a few #ifdefs, I suppose. But it will mean that the binary you build with older MSVC won't install/uninstall properly on 64 bit systems. We should somehow give a warning about this and suggest using a newer compiler. For that #ifdef we need to know which compiler supports the new function. -- I recommend ordering large cargo containers of paper towels to make up whatever budget underruns you have. Paper products are always useful and they have the advantage of being completely flushable if you need to make room in the storage area later. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: uninstal.c RegDeleteKeyEx unresolved
Bram wrote: Build stops at: uninstal.obj : error LNK2001: unresolved external symbol _RegDeleteKeyEx I think RegDeleteKeyEx requires Vista or later, or XP x64. I don't need uninstal, but it breaks the build. I don't think this depends on the OS but on the compiler. I'm building Vim fine on Windows XP. That is with MSVC 2010. We could solve this with a few #ifdefs, I suppose. But it will mean that the binary you build with older MSVC won't install/uninstall properly on 64 bit systems. We should somehow give a warning about this and suggest using a newer compiler. For that #ifdef we need to know which compiler supports the new function. Hmmm. But if installing a newer compiler fixed the problem, that would simply mean that I had installed some library with RegDeleteKeyEx, so the link would be ok. However, the resulting uninstal.exe would not run on other systems without that special library. Googling for 'RegDeleteKeyEx win32' (no quotes) finds lots of hits, including: http://msdn.microsoft.com/en-us/library/ms724847%28VS.85%29.aspx http://stackoverflow.com/questions/1476749/how-do-i-delete-a-registry-entry-in-windows-x64-in-the-64-bit-tree-without-using The first seems to be the official docs, and it says that RegDeleteKeyEx requires Vista or later, or XP x64. The second is a question on exactly the uninstal.c problem: how can an executable run on Windows XP or later, including 64 bit systems, and remove certain registry entries. The ugly suggestion is to load the function dynamically, after determining the runtime environment. Perhaps you could make a macro in uninstal.c: #ifdef _WIN64 then use RegDeleteKeyEx, otherwise user RegDeleteKey. As you say, an exe built on 32 bit would run only on 32 bit. John -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: syntax/tex.vim and conceal support
On Jul 28, 3:55 pm, Charles Campbell wrote:
I've put a new syntax/tex.vim on my website (and have given it to Bram
for inclusion in 7.3). You may try it out by getting it
fromhttp://mysite.verizon.net/astronaut/vim/index.html#vimlinks_syntaxand
clicking ontex.vim.gz . Of course you'll need a gunzip or similar tool
on Windows to decompress the file.
The newtexsyntax file supports setting conceallevel to 2 with utf-8 by
showing appropriate glyphs for Greek in math, a few math symbols in
math, and a number of accented characters.
I personally have little call to use accents in my writing, so I may
well have missed some favorites. If you'd like some accented
character that syntax/tex.vim is presently missing, please send me a
line or two of the form
syn match texAccent '\\c{c}' conceal cchar=
where the '\\c{c}', for example, shows a Vim regex pattern matching the
LaTeX \c{c} which causes to appear. To find the utf-8 glyphs, you may
wish to refer tohttp://www.utf8-chartable.de/unicode-utf8-table.pl.
You can find my email address at the 3rd line of vim73c/syntax/tex.vim .
Hi Chip (and vim_dev),
I really like the idea of using conceal in the tex syntax file but it
still needs some work (I'm basing my comments on the version of
tex.vim that was included in the Sun 1 Aug changeset).
Try the following:
$\eps_b \geq \rho^{-\sigma b}$
- Super/subscripts look weird. The \sigma is typeset as superscript
s i g m a (each letter is a superscript). As it stands I'd rather
have no super/subscripts at all than this weird behavior. (In fact, I
dislike the super/subscripts anyway because they become so tiny that
they are hard to read unless you set your 'gfn' size to something
enormous.)
- Super/subscripts work inconsistently. Note that the _b after
\eps is not turned into a subscript. As far as I understand some
letters are not available as subscripts? Again, I'd rather have no
subscripts at all than to have some letters turn into subscripts but
not others.
- $, { and } are turned into -. Why?
- I can think of a few more things to conceal (off the top of my
head): \infty, \in, \subset (and variants), \cup, \cap, \wedge, \vee,
the list goes forever on (it may be helpful to take a look at short-
math-guide.pdf by Michael Downes)
Anyway, I am grateful for the work you've put into this but there is
definitely room for improvement (my apologies for not simply sending
you a patch but I really should get back to writing that
article... ;-).
Björn
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: uninstal.c RegDeleteKeyEx unresolved
Le Mon, 2 Aug 2010 21:25:05 +1000, John Beckett a écrit dans le message 2504dc3d77fa4577b217bac5971d1...@quartz : Perhaps you could make a macro in uninstal.c: #ifdef _WIN64 then use RegDeleteKeyEx, otherwise user RegDeleteKey. As you say, an exe built on 32 bit would run only on 32 bit. RegDeleteKeyEx was used in 7.2 (macro #ifdef WIN3264) and I can build 7.3b on Win98 using Borland Bcc. In 7.3c KEY_ALL_ACCESS parameter is replaced by KEY_WOW64_64KEY | KEY_ALL_ACCESS. See : ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.3b-7.3c.diff.gz I will try to build this version. -- Patrick Texier -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: uninstal.c RegDeleteKeyEx unresolved
On Mon, 02 Aug 2010 15:16:07 +0200, I wrote: RegDeleteKeyEx was used in 7.2 (macro #ifdef WIN3264) and I can build 7.3b on Win98 using Borland Bcc. In 7.3c KEY_ALL_ACCESS parameter is replaced by KEY_WOW64_64KEY | KEY_ALL_ACCESS. See : ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.3b-7.3c.diff.gz I will try to build this version. Yes, I have errors with KEY_WOW64_64KEY in if_ole.cpp 7.3c: c:\borland\bcc55\BIN\Bcc32 +WIN32\oleobj\bcc.cfg -c -oWIN32\oleobj\if_ol e.obj if_ole.cpp Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland if_ole.cpp: Error E2451 if_ole.cpp 161: Undefined symbol 'KEY_WOW64_64KEY' in function CVim::Create(int *) Error E2451 if_ole.cpp 654: Undefined symbol 'KEY_WOW64_64KEY' in function RecursiveDeleteKey(HKEY__ *,const char *) Error E2451 if_ole.cpp 697: Undefined symbol 'KEY_WOW64_64KEY' in function SetKeyAndValue(const char *,const char *,const char *) *** 3 errors in Compile *** ** error 1 ** deleting WIN32\oleobj\if_ole.obj -- Patrick Texier -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: uninstal.c RegDeleteKeyEx unresolved
On 8/02/10 6:28 AM, Bram Moolenaar wrote: I don't think this depends on the OS but on the compiler. I'm building Vim fine on Windows XP. That is with MSVC 2010. We could solve this with a few #ifdefs, I suppose. But it will mean that the binary you build with older MSVC won't install/uninstall properly on 64 bit systems. We should somehow give a warning about this and suggest using a newer compiler. As I mentioned on the Vim Use mailing list, for MinGW (and Cygwin) at least, RegDeleteKeyEx is defined for WINVER = 0x0502 (Windows XP), but the Make_ming.mak file (and apparently Make_cyg.mak) define WINVER as 0x0400, so RegDeleteKeyEx is undefined unless that value is adjusted. A simple fix for Cygwin and MinGW would be to change the WINVER value in the corresponding makefiles. Chris -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Building the latest vim 7.3 failed to compile on Win XP with MinGW
I'm getting following error: gcc ... -o uninstal.exe uninstal.c -lkernel32 -luser32 -lgdi32 -ladvapi32 -lcomdlg32 -lcomctl32 -lversion -lwsock32 -Lc:/tcl/lib -ltclstub85 C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x24): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x4f): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x79): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xa3): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xcd): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xf7): more undefined references to `RegDeleteKeyEx' follow collect2: ld returned 1 exit status make: *** [uninstal.exe] Error 1 Many thanks in advance, -- Cesar -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: uninstal.c RegDeleteKeyEx unresolved
On Mon, 02 Aug 2010 15:41:48 +0200, I wrote: I will try to build this version. Yes, I have errors with KEY_WOW64_64KEY in if_ole.cpp 7.3c: #define is missing. I can build Vim 7.3c with bcc on Win98 using attached patch. -- Patrick Texier -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php if_ole.patch Description: Binary data
Re: Building the latest vim 7.3 failed to compile on Win XP with MinGW
On 02/08/2010 08:55 a.m., Cesar Romani wrote: I'm getting following error: gcc ... -o uninstal.exe uninstal.c -lkernel32 -luser32 -lgdi32 -ladvapi32 -lcomdlg32 -lcomctl32 -lversion -lwsock32 -Lc:/tcl/lib -ltclstub85 C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x24): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x4f): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x79): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xa3): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xcd): undefined reference to `RegDeleteKeyEx' C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xf7): more undefined references to `RegDeleteKeyEx' follow collect2: ld returned 1 exit status make: *** [uninstal.exe] Error 1 Setting WINVER to 0x0502 on Make_ming.mak works but then it wouldn't work for pre-Win2k systems. -- Cesar -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] MS-Windows uninstaller fail to run on 32 bit systems
On Mon, Aug 2, 2010 at 11:42 AM, Guopeng Wen wenguop...@gmail.com wrote: I found the 7.3d NSIS installer I built cannot uninstall Vim on Windows XP SP3. When I replicate the uninstallation process manually, the following error was reported when launch uninstal.exe: Entry Point Not Found: The procedure entry point RegDeleteKeyExA could not be located in the dynamic link library ADVAPI32.DLL. It turns out RegDeleteKeyEx() is only available on 64 bit Windows, according to MSDN: http://msdn.microsoft.com/en-us/library/ms724847(VS.85).aspx Minimum supported client: Windows Vista, Windows XP Professional x64 Edition That function call was introduced in changeset b204ac54bea4: Fix: the MS-Windows uninstaller did not delete registry keys on 64 bit systems. The simple patch (against changeset 7f578da7edb2) I attached defines a macro REG_DELETE_KEY, which translates to RegDeleteKeyEx when WIN3264 defined, and to RegDeleteKey otherwise. I only tested the patch on Windows XP SP3, it works. I do not have 64-bit system to verify with, it should work in theory since the code is the same after pre-processing when WIN3264 is defined. I should also mention that I built Vim with MinGW, WINVER was set to 0x0500. uninstal.c was built fine but the executable won't run on 32-bit Windows XP. The RegDeleteKeyExA entry point not found in ADVAPI32.DLL error will be reported as mentioned above, and uninstal.exe would abort without doing anything. Regards! -- Guopeng -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Windows 7 double-click file brings up empty vim
On Thu, Jul 29, 2010 at 10:49 AM, Stormy sto...@raincrazy.com wrote: I have the same problem with 7.3b BETA on Windows XP SP3 32-bit, having associated a filetype by right-clicking in Windows Explorer and setting it to always open in gvim.exe. On Jul 28, 3:57 pm, Bram Moolenaar b...@moolenaar.net wrote: Garner Halloran wrote: On Tue, Jul 27, 2010 at 6:52 PM, Ben Fritz fritzophre...@gmail.com wrote: On Jul 20, 9:22 am, Garner Halloran garner...@gmail.com wrote: Using 7.3a BETA on Windows 7. If I double click on any file in explorer that has been associated with gvim it brings up an empty editor. I can drag the file into the window and it will work. I can right click and Edit with Vim and it will work. Gvim is my editor for p4v and if I double click a file there it works. What happens if you set up file associations manually? http://vim.wikia.com/wiki/Windows_file_associations This is probably a problem with the installer...maybe Windows 7 does file associations differently than previous Windows versions? If so we should update the tip as well as the installer. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visithttp://www.vim.org/maillist.php That did not work. I tried this with just a .txt file. assoc .txt=txtfile ftype txtfile=c:\vim\vim73b\gvim.exe --remote-silent %1 It still launches gvim but no text. I also tried this: assoc .=txtfile Then I tried to double-click _vimrc and it opened it up in an existing gvim and replaced one of my buffers. I then closed all of my gvim windows and tried again. Double-clicking _vimrc opened it up in a new window. Very strange. And finally I closed all gvim windows and tried opening a .txt file again, but no luck. I suspect it's a problem with OLE. It registers Vim as a server, but uses the ordinary registry methods. The installer src/dosinst.c was changed to use registry methods that also work for a 32 bit binary running on 64 bit windows. Perhaps someone can look into this and adjust src/if_ole.cpp? -- If all you have is a hammer, everything looks like a nail. When your hammer is C++, everything begins to look like a thumb. -- Steve Hoflich, comp.lang.c++ /// Bram Moolenaar -- b...@moolenaar.net --http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/\\\ \\\download, build and distribute --http://www.A-A-P.org /// \\\help me help AIDS victims --http://ICCF-Holland.org /// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php 7.3c fixes the problem! Thanks! -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
lua available in win32 7.3 beta?
It appears that lua is not compiled in for the 7.3 beta (at least for win32). Was this intentional? I'd love to test this out before release. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: cygwin gcc buidling gvimext.dll fails
Christian J. Robinson wrote: g++-3 -shared -O2 -mno-cygwin -s -o gvimext.dll \ -Wl,--enable-auto-image-base \ -Wl,--enable-auto-import \ -Wl,--whole-archive \ gvimext.o gvimext.res gvimext_ming.def \ -Wl,--no-whole-archive \ -L/lib/w32api -luuid [...]/AppData/Local/Temp/ccISkFaJ.o:uninstal.c:(.text+0x44a): undefined reference to `_RegDeleteKeyEx' [...message repeats...] collect2: ld returned 1 exit status make: *** [uninstal.exe] Error 1 I have just pushed a workaround. No idea if this actually works: # ifndef KEY_WOW64_64KEY # define KEY_WOW64_64KEY 0x0100 # define RegDeleteKeyEx(a, b, c, d) RegDeleteKey(a, b) # endif We might actually need a runtime check too. -- The budget process was invented by an alien race of sadistic beings who resemble large cats. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [bug] access to uninitialized memory in blowfish.c
Dominique Pelle wrote: Vim-7.3d (2467:7f578da7edb2) accesses uninitialized memory when encrypting an empty buffer with cryptmethod=blowfish: $ valgrind --num-callers=50 --track-origins=yes --log-file=/tmp/vg.log \ vim -u NONE -N -c 'set cm=blowfish' \ -c 'call feedkeys(:X\CRfoo\CRfoo\CR:sav! /tmp/foo\CR)' ... and /tmp/vg.log contains: ==6126== Use of uninitialised value of size 4 ==6126==at 0x805C630: bf_e_block (blowfish.c:340) ==6126==by 0x805CCAB: bf_e_cblock (blowfish.c:385) ==6126==by 0x805D20E: bf_crypt_encode (blowfish.c:611) ==6126==by 0x811AFC9: crypt_encode (misc2.c:3868) ==6126==by 0x80FDFFB: ml_encrypt_data (memline.c:4849) ==6126==by 0x80F6422: mf_write_block (memfile.c:1165) ==6126==by 0x80F632D: mf_write (memfile.c:1121) ==6126==by 0x80F59A4: mf_sync (memfile.c:599) ==6126==by 0x80FA11D: ml_preserve (memline.c:2330) ==6126==by 0x80C8919: buf_write (fileio.c:4160) ==6126==by 0x809832D: do_write (ex_cmds.c:2706) ==6126==by 0x8097DF0: ex_write (ex_cmds.c:2519) ==6126==by 0x80A85C8: do_one_cmd (ex_docmd.c:2656) ==6126==by 0x80A5EA1: do_cmdline (ex_docmd.c:1122) ==6126==by 0x812E54B: nv_colon (normal.c:5319) ==6126==by 0x8127BE7: normal_cmd (normal.c:1190) ==6126==by 0x80E8ECF: main_loop (main.c:1260) ==6126==by 0x80E8904: main (main.c:965) ==6126== Uninitialised value was created by a heap allocation ==6126==at 0x4024F70: malloc (vg_replace_malloc.c:236) ==6126==by 0x8117E4E: lalloc (misc2.c:920) ==6126==by 0x8117D3E: alloc (misc2.c:818) ==6126==by 0x80F4F79: mf_open (memfile.c:133) ==6126==by 0x80F68D7: ml_open (memline.c:311) ==6126==by 0x8053830: open_buffer (buffer.c:93) ==6126==by 0x80EABB0: create_windows (main.c:2597) ==6126==by 0x80E8598: main (main.c:809) (and more errors after that) It happens with 'cm=blowfish' but not with 'cm=zip'. I have not found the fix yet. Strange, how can this code use memory allocated in mf_open()? Perhaps that's for mf_seed. Ah yes, for an empty buffer the memfile doesn't exist, mfp-mf_fd 0, and the seed isn't stored. Thus ml_open_file() lacks a call to ml_set_crypt_key(). Something like that. Can you find a fix now? -- Sometimes you can protect millions of dollars in your budget simply by buying a bag of cookies, dropping it on the budget anylyst's desk, and saying something deeply personal such as How was your weekend, big guy? (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: cygwin gcc buidling [uninstal] fails
On Mon, 2 Aug 2010, Bram Moolenaar wrote: Christian J. Robinson wrote: [...]/AppData/Local/Temp/ccISkFaJ.o:uninstal.c:(.text+0x44a): undefined reference to `_RegDeleteKeyEx' I have just pushed a workaround. No idea if this actually works: # ifndef KEY_WOW64_64KEY # define KEY_WOW64_64KEY 0x0100 # define RegDeleteKeyEx(a, b, c, d) RegDeleteKey(a, b) # endif It at least allows compilation without modifying the makefile. Unfortunately I can't test it because I don't actually use the installer/uninstaller; I keep the stable 7.2 release installed globally on my Windows system, and I have a locally installed version for cygwin and just copy the native Windows gvim.exe binary I also build to the same runtime directory so I can run it as well. - Christian -- Christian J. Robinson hept...@gmail.com -- http://christianrobinson.name/ -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Oops (Was: Re: cygwin gcc buidling gvimext.dll fails)
Christian J. Robinson wrote: On Sun, 1 Aug 2010, Chris Sutcliffe wrote: On 8/01/10 7:46 PM, Christian J. Robinson wrote: Oops, the subject should have been uninstal.c, not gvimext.dll The problem is that WINVER is defined as 0x0400 in Make_ming.mak and RegKeyDeleteEx is only available with WINVER 0x0502 and above. I'm using Make_cyg.mak, but the same holds true there. I changed it to 0x0502 and the error disappeared. So we now have a situation where we can either build a version for Win 2000 that won't work on 64-bit windows, or a version that supports 64-bit but won't run on Windows 2000? How about this: # Set the default $(WINVER) use 0x0400 to make the exe work with pre-Win2k WINVER = 0x0502 -- Article in the first Free Software Magazine: Bram Moolenaar studied electrical engineering at the Technical University of Delft and graduated in 1985 on a multi-processor Unix architecture. Response by dimator: Could the school not afford a proper stage for the ceremony? /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net wrote: I have included the recent patches, but not the one that resets recursive in gen_expand_wildcards(). That is probably causing that crash. I noticed that mch_expandpath() is defined on both unix and windows as unix_expandpath() and dos_expandpath(), respectively. I'll see if it can be used in place of globpath() (which calls gen_expand_wildcards()) in the function expand_in_path(). If that is successful I'll send a new patch for that and also revert thechanges I did in globpath() (skipping url path). In the mean time here is the patch to prevent :find tab from crashing on windows when 'path is set to something like c:\src\**. I'm not including this patch. Resetting recursive while it was set elsewhere is wrong. The next call would do the recursive call and cause problems. -- Engineers are always delighted to share wisdom, even in areas in which they have no experience whatsoever. Their logic provides them with inherent insight into any field of expertise. This can be a problem when dealing with the illogical people who believe that knowledge can only be derived through experience. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Mon, Aug 2, 2010 at 8:49 AM, Nazri Ramliy ayieh...@gmail.com wrote: On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net wrote: I have included the recent patches, but not the one that resets recursive in gen_expand_wildcards(). That is probably causing that crash. I noticed that mch_expandpath() is defined on both unix and windows as unix_expandpath() and dos_expandpath(), respectively. I'll see if it can be used in place of globpath() (which calls gen_expand_wildcards()) in the function expand_in_path(). If that is successful I'll send a new patch for that and also revert thechanges I did in globpath() (skipping url path). It turned out that using unix_expandpath() for find completion is much, much slower than using globpath. I ended up using mch_expandpath only when WIN3264 is defined, and use globpath() otherwise. The benchmark result (doing a find completion for jingle.gy in the google chrome source code, the fullname is jingle.gyp): bench.vim: 8 :set path=~/src/chrome/** :find jingle.gy :q 8 Note: there's a single tab character after jingle.gy Result of running $ time ./vim-globpath -s bench.vim; time ./vim-mch_expandpath -s bench.vim for five consecutive runs (whitespaces added to align the timing output below): ./vim-globpath -s bench.vim 0.48s user 1.90s system 92% cpu 2.570 total ./vim-mch_expandpath -s bench.vim 4.26s user 3.97s system 90% cpu 9.135 total ./vim-globpath -s bench.vim 0.53s user 1.64s system 93% cpu 2.310 total ./vim-mch_expandpath -s bench.vim 2.62s user 2.03s system 91% cpu 5.077 total ./vim-globpath -s bench.vim 0.46s user 1.80s system 91% cpu 2.475 total ./vim-mch_expandpath -s bench.vim 3.39s user 3.10s system 86% cpu 7.471 total ./vim-globpath -s bench.vim 0.44s user 1.47s system 88% cpu 2.153 total ./vim-mch_expandpath -s bench.vim 2.00s user 1.92s system 90% cpu 4.350 total ./vim-globpath -s bench.vim 0.47s user 1.46s system 84% cpu 2.271 total ./vim-mch_expandpath -s bench.vim 2.59s user 2.41s system 96% cpu 5.185 total Based on the benchmark result above it appears that using globpath() is about 4 times faster than using mch_expandpath() for doing find completion. Attached patch makes find completion works on windows using mch_expandpath(). On unix we still use globpath(). This is done checking #if defined(WIN3264), I'm not sure if that is the preferred way to detect if we're compiling on windows. In the mean time here is the patch to prevent :find tab from crashing on windows when 'path is set to something like c:\src\**. With the attached patch the above is no longer necessary. For people who would like to test this out, please note the remark in :help 'path': - Careful with '\' characters, type two to get one in the option: :set path=.,c:\\include Or just use '/' instead: :set path=.,c:/include For example use :set path=.,c:\\include\\** or :set path=.,c:/include/** to make vim recursively find completion candidates in c:\include directory. I haven't checked the details, but I have included the patch and made some style changes. I merged the two functions, I don't like duplicating code. -- For humans, honesty is a matter of degree. Engineers are always honest in matters of technology and human relationships. That's why it's a good idea to keep engineers away from customers, romantic interests, and other people who can't handle the truth. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: lua available in win32 7.3 beta?
Garner Halloran wrote: It appears that lua is not compiled in for the 7.3 beta (at least for win32). Was this intentional? I'd love to test this out before release. I do not plan to distribute a Win32 binary with Lua support. You can build it yourself, or perhaps someone will provide it. -- Every engineer dreams about saving the universe and having sex with aliens. This is much more glamorous than the real life of an engineer, which consists of hiding from the universe and having sex without the participation of other life forms. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: lua available in win32 7.3 beta?
Garner Halloran schrob am 02.08.2010 19:54: It appears that lua is not compiled in for the 7.3 beta (at least for win32). Was this intentional? I'd love to test this out before release. My builds are compiled (but untested) with LUA, compiled every few days: http://tuxproject.de/projects/vim -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: lua available in win32 7.3 beta?
On Mon, Aug 2, 2010 at 5:20 PM, Tux der_tux...@arcor.de wrote: Garner Halloran schrob am 02.08.2010 19:54: It appears that lua is not compiled in for the 7.3 beta (at least for win32). Was this intentional? I'd love to test this out before release. My builds are compiled (but untested) with LUA, compiled every few days: http://tuxproject.de/projects/vim -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Much appreciated. I think I will work on compiling my own version in the future as well since I'd prefer a different version of Python. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
On Mon, Aug 2, 2010 at 5:10 PM, Bram Moolenaar b...@moolenaar.net wrote: Nazri Ramliy wrote: On Mon, Aug 2, 2010 at 8:49 AM, Nazri Ramliy ayieh...@gmail.com wrote: On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net wrote: I have included the recent patches, but not the one that resets recursive in gen_expand_wildcards(). That is probably causing that crash. I noticed that mch_expandpath() is defined on both unix and windows as unix_expandpath() and dos_expandpath(), respectively. I'll see if it can be used in place of globpath() (which calls gen_expand_wildcards()) in the function expand_in_path(). If that is successful I'll send a new patch for that and also revert thechanges I did in globpath() (skipping url path). It turned out that using unix_expandpath() for find completion is much, much slower than using globpath. I ended up using mch_expandpath only when WIN3264 is defined, and use globpath() otherwise. The benchmark result (doing a find completion for jingle.gy in the google chrome source code, the fullname is jingle.gyp): bench.vim: 8 :set path=~/src/chrome/** :find jingle.gy :q 8 Note: there's a single tab character after jingle.gy Result of running $ time ./vim-globpath -s bench.vim; time ./vim-mch_expandpath -s bench.vim for five consecutive runs (whitespaces added to align the timing output below): ./vim-globpath -s bench.vim 0.48s user 1.90s system 92% cpu 2.570 total ./vim-mch_expandpath -s bench.vim 4.26s user 3.97s system 90% cpu 9.135 total ./vim-globpath -s bench.vim 0.53s user 1.64s system 93% cpu 2.310 total ./vim-mch_expandpath -s bench.vim 2.62s user 2.03s system 91% cpu 5.077 total ./vim-globpath -s bench.vim 0.46s user 1.80s system 91% cpu 2.475 total ./vim-mch_expandpath -s bench.vim 3.39s user 3.10s system 86% cpu 7.471 total ./vim-globpath -s bench.vim 0.44s user 1.47s system 88% cpu 2.153 total ./vim-mch_expandpath -s bench.vim 2.00s user 1.92s system 90% cpu 4.350 total ./vim-globpath -s bench.vim 0.47s user 1.46s system 84% cpu 2.271 total ./vim-mch_expandpath -s bench.vim 2.59s user 2.41s system 96% cpu 5.185 total Based on the benchmark result above it appears that using globpath() is about 4 times faster than using mch_expandpath() for doing find completion. Attached patch makes find completion works on windows using mch_expandpath(). On unix we still use globpath(). This is done checking #if defined(WIN3264), I'm not sure if that is the preferred way to detect if we're compiling on windows. In the mean time here is the patch to prevent :find tab from crashing on windows when 'path is set to something like c:\src\**. With the attached patch the above is no longer necessary. For people who would like to test this out, please note the remark in :help 'path': - Careful with '\' characters, type two to get one in the option: :set path=.,c:\\include Or just use '/' instead: :set path=.,c:/include For example use :set path=.,c:\\include\\** or :set path=.,c:/include/** to make vim recursively find completion candidates in c:\include directory. I haven't checked the details, but I have included the patch and made some style changes. I merged the two functions, I don't like duplicating code. Revision: 7d1044b27e On WinXP, attempting find completion leads to a crash. gvim -N -u NONE a.tex :find Tab Vim crashes The same happens with :find aTab Ajit -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: lua available in win32 7.3 beta?
Garner Halloran schrob am 02.08.2010 23:36: Much appreciated. I think I will work on compiling my own version in the future as well since I'd prefer a different version of Python. Which and why? Maybe I could switch, too. ;-) -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
On Tue, Aug 3, 2010 at 7:51 AM, Ajit Thakkar a...@unb.ca wrote: Revision: 7d1044b27e On WinXP, attempting find completion leads to a crash. gvim -N -u NONE a.tex :find Tab Vim crashes The same happens with :find aTab Ajit Thanks for testing it. I'll investigate the crash. nazri. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
On Tue, Aug 3, 2010 at 8:07 AM, Nazri Ramliy ayieh...@gmail.com wrote:
On Tue, Aug 3, 2010 at 7:51 AM, Ajit Thakkar a...@unb.ca wrote:
Revision: 7d1044b27e
On WinXP, attempting find completion leads to a crash.
gvim -N -u NONE a.tex
:find Tab
Vim crashes
The same happens with
:find aTab
Ajit
Thanks for testing it.
I'll investigate the crash.
Attached is the fix on top of Revision: 7d1044b27e.
nazri.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
From 0e74ad37a897ea651ac3671b8d442ac4601ad754 Mon Sep 17 00:00:00 2001
From: nazri ayieh...@gmail.com
Date: Tue, 3 Aug 2010 08:25:43 +0800
Subject: [PATCH] Fix use of unallocated buffer for find completion on windows
---
src/misc1.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/misc1.c b/src/misc1.c
index e564c5c..6e988fa 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9586,6 +9586,11 @@ expand_in_path(gap, pattern, flags)
return 0;
mch_dirname(curdir, MAXPATHL);
+# ifdef WIN3264
+if ((file_pattern = alloc((int)(MAXPATHL))) == NULL)
+ return 0;
+# endif
+
expand_path_option(curdir, path_ga);
vim_free(curdir);
path_list = (char_u **)(path_ga.ga_data);
@@ -9599,6 +9604,8 @@ expand_in_path(gap, pattern, flags)
STRCAT(file_pattern, pattern);
mch_expandpath(gap, file_pattern, EW_DIR|EW_ADDSLASH|EW_FILE);
}
+
+vim_free(file_pattern);
# else
for (i = 0; i path_ga.ga_len; i++)
{
--
1.7.2.1.6.g61bf12
Re: lua available in win32 7.3 beta?
On Mon, Aug 2, 2010 at 7:55 PM, Tux der_tux...@arcor.de wrote: Garner Halloran schrob am 02.08.2010 23:36: Much appreciated. I think I will work on compiling my own version in the future as well since I'd prefer a different version of Python. Which and why? Maybe I could switch, too. ;-) -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php I'm using 2.7 at work and would prefer to stay in the Python 2 realm for now. I've been meaning to learn how to compile Vim for awhile so now I have a good excuse! -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] MS-Windows uninstaller fail to run on 32 bit systems
On Tue, Aug 3, 2010 at 5:12 AM, Bram Moolenaar b...@moolenaar.net wrote: I wrote: Guopeng Wen wrote: I found the 7.3d NSIS installer I built cannot uninstall Vim on Windows XP SP3. When I replicate the uninstallation process manually, the following error was reported when launch uninstal.exe: Entry Point Not Found: The procedure entry point RegDeleteKeyExA could not be located in the dynamic link library ADVAPI32.DLL. It turns out RegDeleteKeyEx() is only available on 64 bit Windows, according to MSDN: http://msdn.microsoft.com/en-us/library/ms724847(VS.85).aspx Minimum supported client: Windows Vista, Windows XP Professional x64 Edition That function call was introduced in changeset b204ac54bea4: Fix: the MS-Windows uninstaller did not delete registry keys on 64 bit systems. The simple patch (against changeset 7f578da7edb2) I attached defines a macro REG_DELETE_KEY, which translates to RegDeleteKeyEx when WIN3264 defined, and to RegDeleteKey otherwise. I only tested the patch on Windows XP SP3, it works. I do not have 64-bit system to verify with, it should work in theory since the code is the same after pre-processing when WIN3264 is defined. It does work on my Windows XP system. Apparently it's hard to predict if RegDeleteKeyEx() is going to work. This would require using LoadLibrary() and GetProcAddress(). I have implemented this now. It appears to work OK (tested on Windows XP and Windows 7 64 bit). Let me know if there are still build problems and uninstall problems (if you build it yourself). I built and tested the latest mercurial version (7d1044b27eb5), now the uninstaller works correctly, thanks! BTW, I built with MinGW, with WINVER set to 0x0500. I saw the WIN3264 macro and thought there might be a 64-bit special build using that macro. Apparently I made the wrong assumption and my patch won't work for 64-bit systems. Late binding is the correct way to go. I guess the reason why RegDeleteKeyEx() works on some systems but not others is certain Microsoft product (most likely MS Visual Studio 2010) upgraded windows/system32/advapi32.dll silently. My system is Windows XP professional, with every possible patches applied, and the version of the said DLL is: Advanced Windows 32 Base API File Version: 5.1.2600.5755 (xpsp_sp3_gdr.090206-1234) Probably off topic. If I can make silent mode of the NSIS installer works reasonably well (so we can install/uninstall from command line without any mouse click), is there any concern if I migrate functionality of install.c/uninstal.c into NSIS script? In this way, we may avoid the mess we've just encountered in the future, the installer (or the script) should take care of version compatibility issue. Regards! -- Guopeng -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: lua available in win32 7.3 beta
Garner Halloran schrob am 03.08.2010 02:47: I'm using 2.7 at work and would prefer to stay in the Python 2 realm for now. My builds use both Python 2 and 3. For compiling trunk builds I use the attached batch file, Visual Studio 2010 (you might have to change some paths accordingly). Loosely commented, working fine with Windows 7 (German, so C:\Programme is a hard link to C:\Program Files, but I wanted to avoid paths with spaces). -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php compile.7z Description: Binary data
Provide latest gvim.exe of mine
I compile the vim from the latest source of Mercurial Repository with version 2474. I provide the gvim.exe file download address if anyone want it. Compile by mingw gcc (GCC) 3.4.5 on WindowsXP platform: Support python2.X Support Lua5.1 Support Perl5.6 Download Address: Support Py26: http://vim-winterttr.googlecode.com/hg/bin/gvim.exe Support py25: http://vim-winterttr.googlecode.com/hg/bin/gvim_py25.exe -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
syntax/diff.vim minor bug and locale problem
Hi, When running diff without options, removed lines are separated of added ones by '^---$'. This pattern gets interpreted as diffRemoved when it is not. I think the pattern can be classified as diffLine. If I'm not interpreting it wrongly the attached patch fix this tiny bug. Locale problem: The diff in languages other than English may generate output that doesn't match the patterns for diffOnly, diffDiffer, etc. because diff messages get translated in some languages. To fix this for my locale (pt_BR.UTF-8) I've put in my ~/.vim/after/syntax/diff.vim the following lines: syn match diffOnly ^[A-Z].* syn match diffIdentical ^[A-Z].* syn match diffDiffer^[A-Z].* syn match diffBDiffer ^[A-Z].* syn match diffIsA ^[A-Z].* syn match diffNoEOL ^[A-Z].* syn match diffCommon^[A-Z].* I repeated the same pattern because sometimes I use the terminal emulator in English and the above patterns will still be fine. A more general solution would be to define the above syntax elements first using the pattern ^\S.* and, then, define the other syntax elements. This approach would have at least one shortcoming: the distinction between diffOnly, diffidentical, etc. would be lost. Best regards, Jakson -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php diff -r 7d1044b27eb5 runtime/syntax/diff.vim --- a/runtime/syntax/diff.vim Mon Aug 02 23:06:46 2010 +0200 +++ b/runtime/syntax/diff.vim Mon Aug 02 22:33:26 2010 -0300 @@ -26,6 +26,7 @@ syn match diffLine ^...@.* contains=diffSubname syn match diffLine ^\\d\+\.* syn match diffLine ^\*\*\*\*.* +syn match diffLine ^---$ Some versions of diff have lines like #c# and #d# (where # is a number) syn match diffLine ^\d\+\(,\d\+\)\=[cda]\d\+\.*
Re: lua available in win32 7.3 beta
For compiling trunk builds I use the attached batch file, Visual Studio 2010 (you might have to change some paths accordingly). Loosely commented, working fine with Windows 7 (German, so C:\Programme is a hard link to C:\Program Files, but I wanted to avoid paths with spaces). It's straightforward to include Lua (not LUA) in Vim 7.3: 1. Install Lua: the usual Lua installation in Windows is luaforwindows, http://code.google.com/p/luaforwindows . You'll need Lua Module Development files (libs and headers). (Around 8Mb after installed.) 2. Compile: after installing Lua, just compile Vim with, say, nmake -f Make_mvc.mak GUI=yes OLE=yes LUA=C:\Progra~1\Lua\5.1 DYNAMIC_LUA=yes if using Visual Studio, or mingw32-make -f Make_ming.mak GUI=yes OLE=yes LUA=C:\Progra~1\Lua\5.1 if using MinGW (DYNAMIC_LUA=yes by default). Of course, you can add your other options for more features. I think it'd be nice to have all language interfaces (/dyn) in the Windows version of Vim, that is, to have Lua and MzScheme included. But I don't know how hard it is to include MzScheme. Lua is easy; don't you agree, Bram? :) Cheers, Luis -- Computers are useless. They can only give you answers. -- Pablo Picasso -- Luis Carvalho (Kozure) lua -e 'print(((lexcarva...@no.gmail.spam.com):gsub((%u+%.),)))' -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: lua available in win32 7.3 beta
On Tue, Aug 03, 2010 at 04:24:00AM +0200, Tux wrote: Luis Carvalho schrob am 03.08.2010 04:15: 2. Compile: after installing Lua, just compile Vim with, say, nmake -f Make_mvc.mak GUI=yes OLE=yes LUA=C:\Progra~1\Lua\5.1 DYNAMIC_LUA=yes That's (almost) how I do it. Hmm, MzScheme; I would have included it in my builds if I had found a native Win32 version. But I haven't, so i haven't. Any hints? Racket (formerly called PLT Scheme) is available at http://www.racket-lang.org/. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: lua available in win32 7.3 beta
James Vega schrob am 03.08.2010 04:54: Racket (formerly called PLT Scheme) is available at http://www.racket-lang.org/. Racket is not compatible with the Vim makefiles which require mzScheme libs explicitly. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
