Re: [PATCH] if_lua (was: if_lua patch)
On Sun, Sep 2, 2012 at 2:39 AM Luis Carvalho wrote:
> ZyX wrote:
> > > No, since the patches are few and far between.
> >
> > Pulling patches from the repository and saving them there is
> > convenient. When I was adding third argument to sort() patch was also
> > not big but I still cloned vim to bitbucket. This decision appeared to
> > be right when I started to extend python interface.
> >
> > Even if you don’t want to create commits, do use “hg diff”. Two
> > patches for two files with requirement to switch to another directory
> > before applying each one is very inconvenient.
>
> OK, thanks for the suggestion. I'm attaching a patch generated by 'hg diff'.
> To summarize the main changes:
>
> - New funcref type, including new vim.funcref() function
> - vim.dict() and vim.list() now accept an initializer table as argument
> - Updated docs
> - A few bug fixes (following this thread)
>
>
> > > I don't think that's an error in if_lua: the documentation doesn't say
> > > anything about dictionaries not allowing empty strings as keys -- :help
> > > Dictionary only says that 'a key is always a String' -- and hence the
> > > absence
> > > of error when printing d in your example. What is not allowed is for you
> > > to
> > > read or set empty keys in Vim (using 'let'), but I don't want to replicate
> > > that in if_lua. For instance, you can do this:
> > >
> > > vim -u NONE -c 'let d={} | lua vim.eval("d")[""] = "empty"'
> > > -c 'for [k,v] in items(d) | echo "|".k."| -> ".v | endfor'
> > >
> > > So, to be consistent, if you set an empty key in if_lua, you can read or
> > > reset
> > > it there.
> >
> > Yes, you can do “for [k, v] in items(d)”. But you can’t do “for k in
> > keys(d) | let v=d[k]”. I can’t prove that this won’t break anything,
> > maybe you can?
> >
> > Help does not mention this probably because error message is clear
> > enough, I constantly see such things in a doc: “:h E???” exists, but
> > in the text there is nothing concerning error message.
>
> I agree that there must be a reason for the parser to avoid empty strings, but
> then the documentation should change to reflect this behavior. Ideally this
> behavior should be coded in the API, probably making dict_add check the
> dictitem argument. While I still maintain that that's not an if_lua issue,
> I've updated the code to check for empty keys when setting dict entries, just
> in case it breaks something and for consistency.
>
> > >> And you have missed another error:
> > >>
> > >> vim -u NONE -c 'lua vim.eval("g:")["input"]=vim.funcref("tr")' -c
> > >> 'call input("Yes?")'
> > >>
> > >> results in an error “not enough arguments to tr” while it should result
> > >> in an error “funcref variables must start with a capital” (see my patch
> > >> to python interface [1] and extend() function [2]).
> > >
> > > There's no error here either. The problem is that tr() expects three
> > > arguments, and not that the variable must start with a capital letter
> > > (g:input
> > > already exists.) Try this:
> > >
> > > vim -u NONE -c 'lua vim.eval("g:").input=vim.funcref("tolower")'
> > > -c 'echo input("Yes?")'
> >
> > It is just an example. Vim has very weird way of disallowing
> > overriding built-in and user functions: a check everywhere you can add
> > a value to a dictionary. The fact that you *allow overriding built-in
> > functions* is an error. Not the fact that “tr” expects three arguments
> > or something else.
> >
> > Existence of your behavior in lua interface and my in python (unlike
> > my patch to extend() patch to if_py* was not merged) defeats the
> > purpose of such checks.
>
> Again, the issue here is not that funcref variables must start with a capital
> letter -- only the parser should check that, not if_lua -- but that if_lua is
> assigning funcrefs to a "builtin" scope dictionary (g: or l:). The fix is
> straightforward: if_lua now checks if dict->dv_scope == VAR_DEF_SCOPE and if
> the value is a funcref and complains if that's the case.
>
> > > I think you're mixing the fact that Vim Funcref variables should start
> > > with a
> > > capital letter. Funcrefs in lua are just a value; for instance, this
> > > should
> > > work:
> > >
> > > :lua print(vim.funcref"tr"("", "<>", "{}"))
> > > " {tag}
> >
> > No, I am not. I do not care how you can name funcrefs in lua, you must
> > not allow using lua to override built-in or user functions by adding
> > something to scope dictionary. The proper way of fixing this all is
> > modifying parser, but modifying lua interface is much simpler. If you
>
> As I said, you shouldn't really care about Lua "naming" funcrefs, since that's
> a moot point (funcrefs in Lua are just values, they have no names.) But you're
> right that the issue is checking for the dictionary to be a scope; see comment
> above.
>
> > can modify the parser go ahead and get rid of E704 and E705: in the
> > current state there is exactly no way to safely assign funcref to a
> > variable,
Re: Patch 8.1.0128
On Sun, Jul 1, 2018 at 2:59 AM, John Little wrote: > On Sunday, July 1, 2018 at 2:28:04 AM UTC+12, Bram Moolenaar wrote: >> Patch 8.1.0128 > > Just noticed version.c on github doesn't have patch number 128. No effect, > other than a little confusion. > > Regards, John Little Nor does it on the Mercurial mirror: I hadn't noticed, but now that you mention it, with all patches so far I see: Included patches: 1-127, 129-133 Best regards, Tony. -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0128
On Sunday, July 1, 2018 at 2:28:04 AM UTC+12, Bram Moolenaar wrote: > Patch 8.1.0128 Just noticed version.c on github doesn't have patch number 128. No effect, other than a little confusion. Regards, John Little -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0128
* Bram Moolenaar [2018-06-30 16:27 +0200]: > > Patch 8.1.0128 > Problem:Building with MinGW does not work out-of-the-box. > Solution: Add instructions for MSYS2. Set default WINVER. Add batch files > to set $PATH for MSYS2. > Files:src/Make_cyg_ming.mak, src/INSTALLpc.txt, src/msys32.bat, > src/msys64.bat, Filelist The patch number isn't mentioned in src/version.c. Elimar -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Trying to build with MinGW
Hi Bram, 2018/7/1 Sun 5:02:50 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > [...] > > > > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the > > > > following > > > > command to install them: > > > > > > > > pacman -S base-devel mingw-w64-i686-toolchain > > > > mingw-w64-x86_64-toolchain > > > > > > > > Or you can use the `pacboy` command to avoid long package names: > > > > > > > > pacboy -S base-devel: toolchain:m > > > > > > This asks what packages to install. Should this install "all"? > > > It installs an awful lot of stuff, it says it uses 1.5 Gbyte. > > > My laptop is almost full... > > > > If you only want to build 32-bit Vim, you don't need to install the x86_64 > > toolchain. In this case, you can use one of the following commands: > > > > pacman -S base-devel mingw-w64-i686-toolchain > > or: > > pacboy -S base-devel: toolchain:i > > (The ":i" suffix means i686 only.) > > > > If you only want to build 64-bit Vim, you don't need to install the i686 > > toolchain. In this case, you can use one of the following commands: > > > > pacman -S base-devel mingw-w64-x86_64-toolchain > > or: > > pacboy -S base-devel: toolchain:x > > (The ":x" suffix means x86_64 only.) > > > > > > Some of the package might not be needed for building Vim, but I haven't > > checked which is necessary and which is not. > > The above package groups are generally useful for building many kind of > > programs. > > I deleted the 64 bit directory, that was 700 Mbyte. Now the 32 bit > directory is still taking 700 Mbyte. It would be useful to find out how > to reduce that. You can refer Arch Wiki for general usage of the pacman command: https://wiki.archlinux.org/index.php/pacman To remove x64_86 toolchain, try: pacman -R mingw-w64-x86_64-toolchain or: pacman -R toolchain:x Also you can clean the package cache. The downloaded packages are stored in the C:\msys64\var\cache\pacman\pkg directory. See the following part for how to clean it: https://wiki.archlinux.org/index.php/pacman#Cleaning_the_package_cache (Or you can remove the files manually. It is not recommended, though.) > > > That uses the MSYS console, where just about nothing works. "git pull" > > > doesn't work. Can't even run the Vim I just build in it. How to build > > > Vim in a normal Windows console? > > > > When the MSYS2 console is executed, MSYS2 stops exporting the current $PATH > > by default. If you want to use git in MSYS2 console, there are two ways. > > > > 1. Change the MSYS2 setting to export the current $PATH > >See C:\msys64\msys2_shell.cmd for detail. > > 2. Install the MSYS2 version of git > >MSYS2 has its own version of git. You can install it by pacman/pacboy. > > I don't really want to use the MSYS2 console, it's like using Linux on a > Windows system. When doing "pwd" I see a different home directory, > among other surprises. I prefer using the Windows console, since that > is what most people will be using. Okay, but some other people want to use the MSYS2 console. We might be able to improve the instructions for those people. Regards, Ken Takata -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 8.1.0133
Patch 8.1.0133
Problem:tagfiles() can have duplicate entries.
Solution: Simplify the filename to make checking for duplicates work better.
Add a test. (Dominique Pelle, closes #2979)
Files: src/tag.c, src/testdir/test_taglist.vim
*** ../vim-8.1.0132/src/tag.c 2018-04-27 22:44:39.0 +0200
--- src/tag.c 2018-06-30 22:40:27.157629813 +0200
***
*** 2595,2601
}
static garray_T tag_fnames = GA_EMPTY;
- static void found_tagfile_cb(char_u *fname, void *cookie);
/*
* Callback function for finding all "tags" and "tags-??" files in
--- 2595,2600
***
*** 2605,2612
found_tagfile_cb(char_u *fname, void *cookie UNUSED)
{
if (ga_grow(_fnames, 1) == OK)
! ((char_u **)(tag_fnames.ga_data))[tag_fnames.ga_len++] =
! vim_strsave(fname);
}
#if defined(EXITFREE) || defined(PROTO)
--- 2604,2618
found_tagfile_cb(char_u *fname, void *cookie UNUSED)
{
if (ga_grow(_fnames, 1) == OK)
! {
! char_u *tag_fname = vim_strsave(fname);
!
! #ifdef BACKSLASH_IN_FILENAME
! slash_adjust(tag_fname);
! #endif
! simplify_filename(tag_fname);
! ((char_u **)(tag_fnames.ga_data))[tag_fnames.ga_len++] = tag_fname;
! }
}
#if defined(EXITFREE) || defined(PROTO)
***
*** 2638,2643
--- 2644,2650
{
char_u*fname = NULL;
char_u*r_ptr;
+ int i;
if (first)
vim_memset(tnp, 0, sizeof(tagname_T));
***
*** 2679,2684
--- 2686,2699
++tnp->tn_hf_idx;
STRCPY(buf, p_hf);
STRCPY(gettail(buf), "tags");
+ #ifdef BACKSLASH_IN_FILENAME
+ slash_adjust(buf);
+ #endif
+ simplify_filename(buf);
+
+ for (i = 0; i < tag_fnames.ga_len; ++i)
+ if (STRCMP(buf, ((char_u **)(tag_fnames.ga_data))[i]) == 0)
+ return FAIL; // avoid duplicate file names
}
else
vim_strncpy(buf, ((char_u **)(tag_fnames.ga_data))[
*** ../vim-8.1.0132/src/testdir/test_taglist.vim2018-02-09
18:25:21.0 +0100
--- src/testdir/test_taglist.vim2018-06-30 22:33:05.044664951 +0200
***
*** 1,4
! " test 'taglist' function and :tags command
func Test_taglist()
call writefile([
--- 1,4
! " test taglist(), tagfiles() functions and :tags command
func Test_taglist()
call writefile([
***
*** 61,63
--- 61,86
call assert_fails('tag ' . repeat('x', 1020), 'E426')
tags
endfunc
+
+ func Test_tagfiles()
+ call assert_equal([], tagfiles())
+
+ call writefile(["FFoo\tXfoo\t1"], 'Xtags1')
+ call writefile(["FBar\tXbar\t1"], 'Xtags2')
+ set tags=Xtags1,Xtags2
+ call assert_equal(['Xtags1', 'Xtags2'], tagfiles())
+
+ help
+ let tf = tagfiles()
+ call assert_equal(1, len(tf))
+ call assert_equal(fnamemodify(expand('$VIMRUNTIME/doc/tags'),
':p:gs?\\?/?'),
+ \ fnamemodify(tf[0], ':p:gs?\\?/?'))
+ helpclose
+ call assert_equal(['Xtags1', 'Xtags2'], tagfiles())
+ set tags&
+ call assert_equal([], tagfiles())
+
+ call delete('Xtags1')
+ call delete('Xtags2')
+ bd
+ endfunc
*** ../vim-8.1.0132/src/version.c 2018-06-30 21:50:16.856674912 +0200
--- src/version.c 2018-06-30 22:33:36.756434678 +0200
***
*** 791,792
--- 791,794
{ /* Add new patch number below this line */
+ /**/
+ 133,
/**/
--
hundred-and-one symptoms of being an internet addict:
158. You get a tuner card so you can watch TV while surfing.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Trying to build with MinGW
Ken Takata wrote: [...] > > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the > > > following > > > command to install them: > > > > > > pacman -S base-devel mingw-w64-i686-toolchain > > > mingw-w64-x86_64-toolchain > > > > > > Or you can use the `pacboy` command to avoid long package names: > > > > > > pacboy -S base-devel: toolchain:m > > > > This asks what packages to install. Should this install "all"? > > It installs an awful lot of stuff, it says it uses 1.5 Gbyte. > > My laptop is almost full... > > If you only want to build 32-bit Vim, you don't need to install the x86_64 > toolchain. In this case, you can use one of the following commands: > > pacman -S base-devel mingw-w64-i686-toolchain > or: > pacboy -S base-devel: toolchain:i > (The ":i" suffix means i686 only.) > > If you only want to build 64-bit Vim, you don't need to install the i686 > toolchain. In this case, you can use one of the following commands: > > pacman -S base-devel mingw-w64-x86_64-toolchain > or: > pacboy -S base-devel: toolchain:x > (The ":x" suffix means x86_64 only.) > > > Some of the package might not be needed for building Vim, but I haven't > checked which is necessary and which is not. > The above package groups are generally useful for building many kind of > programs. I deleted the 64 bit directory, that was 700 Mbyte. Now the 32 bit directory is still taking 700 Mbyte. It would be useful to find out how to reduce that. > > That uses the MSYS console, where just about nothing works. "git pull" > > doesn't work. Can't even run the Vim I just build in it. How to build > > Vim in a normal Windows console? > > When the MSYS2 console is executed, MSYS2 stops exporting the current $PATH > by default. If you want to use git in MSYS2 console, there are two ways. > > 1. Change the MSYS2 setting to export the current $PATH >See C:\msys64\msys2_shell.cmd for detail. > 2. Install the MSYS2 version of git >MSYS2 has its own version of git. You can install it by pacman/pacboy. I don't really want to use the MSYS2 console, it's like using Linux on a Windows system. When doing "pwd" I see a different home directory, among other surprises. I prefer using the Windows console, since that is what most people will be using. -- hundred-and-one symptoms of being an internet addict: 157. You fum through a magazine, you first check to see if it has a web address. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 8.1.0132
Patch 8.1.0132
Problem:Lua tests are old style.
Solution: Convert to new style tests. Improve coverage. (Dominique Pelle,
closes #3091)
Files: src/Makefile, src/testdir/Make_all.mak,
src/testdir/Make_amiga.mak, src/testdir/Make_vms.mms,
src/testdir/test85.in, src/testdir/test_lua.vim
*** ../vim-8.1.0131/src/Makefile2018-06-23 19:22:45.618486231 +0200
--- src/Makefile2018-06-30 21:22:17.965276852 +0200
***
*** 2119,2125
test52 test59 \
test64 test69 \
test70 test72 \
! test85 test86 test87 test88 \
test94 test95 test99 test108:
cd testdir; rm -f $@.out; $(MAKE) -f Makefile $@.out
VIMPROG=../$(VIMTESTTARGET) $(GUI_TESTARG) SCRIPTSOURCE=../$(SCRIPTSOURCE)
--- 2119,2125
test52 test59 \
test64 test69 \
test70 test72 \
! test86 test87 test88 \
test94 test95 test99 test108:
cd testdir; rm -f $@.out; $(MAKE) -f Makefile $@.out
VIMPROG=../$(VIMTESTTARGET) $(GUI_TESTARG) SCRIPTSOURCE=../$(SCRIPTSOURCE)
*** ../vim-8.1.0131/src/testdir/Make_all.mak2018-06-23 19:22:45.614486258
+0200
--- src/testdir/Make_all.mak2018-06-30 21:20:58.605620983 +0200
***
*** 36,42
SCRIPTS_MORE1 = \
test11.out \
test52.out \
- test85.out \
test86.out \
test87.out
--- 36,41
*** ../vim-8.1.0131/src/testdir/Make_amiga.mak 2017-11-02 20:58:54.0
+0100
--- src/testdir/Make_amiga.mak 2018-06-30 21:20:58.605620983 +0200
***
*** 14,20
# test10 'errorformat' is different
# test11 "cat" doesn't work properly
# test52 only for Win32
- # test85 no Lua interface
# test86, 87 no Python interface
SCRIPTS = $(SCRIPTS_ALL) $(SCRIPTS_MORE4)
--- 14,19
*** ../vim-8.1.0131/src/testdir/Make_vms.mms2018-01-31 19:23:08.0
+0100
--- src/testdir/Make_vms.mms2018-06-30 21:20:58.605620983 +0200
***
*** 93,99
#
# test72: bug - Vim hangs at :rename (while rename works well otherwise)
# test78: bug - Vim dies at :recover Xtest
- # test85: no Lua interface
# test89: bug - findfile() does not work on VMS (just in the current
directory)
# test102: Just ODS-5 supports space and special chars in the filename.
# On ODS-2 tests fail.
--- 93,98
***
*** 119,127
SCRIPT_MZSCH = test70.out
.ENDIF
! .IFDEF HAVE_ODS5
! SCRIPT_ODS5 = test102.out
! .ENDIF
.IFDEF HAVE_GZIP
SCRIPT_GZIP = test11.out
--- 118,126
SCRIPT_MZSCH = test70.out
.ENDIF
! .IFDEF HAVE_ODS5
! SCRIPT_ODS5 = test102.out
! .ENDIF
.IFDEF HAVE_GZIP
SCRIPT_GZIP = test11.out
***
*** 131,140
SCRIPT_GDIFF = test47.out
.ENDIF
- .IFDEF HAVE_LUA
- SCRIPT_LUA = test85.out
- .ENDIF
-
.IFDEF HAVE_PYTHON
SCRIPT_PYTHON = test86.out test87.out
.ENDIF
--- 130,135
*** ../vim-8.1.0131/src/testdir/test85.in 2017-03-08 22:48:59.0
+0100
--- src/testdir/test85.in 1970-01-01 01:00:00.0 +0100
***
*** 1,86
- Test for Lua interface and luaeval() function
-
- STARTTEST
- :so small.vim
- :set belloff=all
- :so lua.vim
- :set nocompatible viminfo+=nviminfo
- :lua l = vim.list():add"item0":add"dictionary with list OK":add"item2"
- :lua h = vim.dict(); h.list = l
- :call garbagecollect()
- /^1
- :" change buffer contents
- :lua curbuf = vim.buffer()
- :lua curline = vim.eval"line('.')"
- :lua curbuf[curline] = "1 changed line 1"
- :" scalar test
- :let tmp_string = luaeval('"string"')
- :let tmp_1000 = luaeval('1000')
- :if printf("%s%.0f", tmp_string, tmp_1000) == "string1000"
- :let scalar_res = "OK"
- :else
- :let scalar_res = "FAILED"
- :endif
- :call append(search("^1"), "scalar test " . scalar_res)
- :" dictionary containing a list
- :let tmp = luaeval("h").list[1]
- :/^2/put =tmp
- :" circular list (at the same time test lists containing lists)
- :lua l[2] = l
- :let l2 = luaeval("h").list
- :if l2[2] == l2
- :let res = "OK"
- :else
- :let res = "FAILED"
- :endif
- :call setline(search("^3"), "circular test " . res)
-
- :let l = []
- :lua l = vim.eval("l")
- :lua l:add(123)
- :lua l:add("abc")
- :lua l:add(vim.eval("[1, 2, 3]"))
- :lua l:add(vim.eval("{'a':1, 'b':2, 'c':3}"))
- :lua l:insert(123)
- :lua l:insert("abc")
- :lua l:insert(vim.eval("[1, 2, 3]"))
- :lua l:insert(vim.eval("{'a':1, 'b':2, 'c':3}"))
- :lua l[0] = l[0]
- :lua l[1] = l[1]
- :lua l[2] = l[2]
- :lua l[3] = l[3]
- :lua l[0] = 123
- :lua l[1] = "abc"
- :lua l[2] = vim.eval("[1, 2, 3]")
- :lua l[3] = vim.eval("{'a':1, 'b':2, 'c':3}")
- :lua l[3] = nil
- :lua l[2] = nil
- :lua l[1] = nil
- :lua l[0] = nil
- :lua l = nil
- :$put
Patch 8.1.0131
Patch 8.1.0131
Problem::profdel is not tested.
Solution: Add a test. (Dominique Pelle, closes #3123)
Files: src/testdir/test_profile.vim
*** ../vim-8.1.0130/src/testdir/test_profile.vim2017-12-05
16:42:08.0 +0100
--- src/testdir/test_profile.vim2018-06-30 21:16:50.974593817 +0200
***
*** 5,10
--- 5,12
func Test_profile_func()
let lines = [
+ \ 'profile start Xprofile_func.log',
+ \ 'profile func Foo*"',
\ "func! Foo1()",
\ "endfunc",
\ "func! Foo2()",
***
*** 33,41
call writefile(lines, 'Xprofile_func.vim')
call system(v:progpath
! \ . ' -es -u NONE -U NONE -i NONE --noplugin'
! \ . ' -c "profile start Xprofile_func.log"'
! \ . ' -c "profile func Foo*"'
\ . ' -c "so Xprofile_func.vim"'
\ . ' -c "qall!"')
call assert_equal(0, v:shell_error)
--- 35,41
call writefile(lines, 'Xprofile_func.vim')
call system(v:progpath
! \ . ' -es --clean'
\ . ' -c "so Xprofile_func.vim"'
\ . ' -c "qall!"')
call assert_equal(0, v:shell_error)
***
*** 97,103
call writefile(lines, 'Xprofile_file.vim')
call system(v:progpath
! \ . ' -es -u NONE -U NONE -i NONE --noplugin'
\ . ' -c "profile start Xprofile_file.log"'
\ . ' -c "profile file Xprofile_file.vim"'
\ . ' -c "so Xprofile_file.vim"'
--- 97,103
call writefile(lines, 'Xprofile_file.vim')
call system(v:progpath
! \ . ' -es --clean'
\ . ' -c "profile start Xprofile_file.log"'
\ . ' -c "profile file Xprofile_file.vim"'
\ . ' -c "so Xprofile_file.vim"'
***
*** 152,168
let lines = readfile('Xprofile_file.log')
call assert_equal(11, len(lines))
! call assert_match('^SCRIPT .*Xprofile_file.vim$',
lines[0])
! call assert_equal('Sourced 1 time',lines[1])
! call assert_match('^Total time:\s\+\d\+\.\d\+$',
lines[2])
! call assert_match('^ Self time:\s\+\d\+\.\d\+$',
lines[3])
! call assert_equal('',
lines[4])
! call assert_equal('count total (s) self (s)',
lines[5])
! call assert_match('1 0.\d\+ echo "hello',
lines[6])
! call assert_equal(' \ world"',
lines[7])
! call assert_match('1 0.\d\+ echo "foo ',
lines[8])
! call assert_equal(' \bar"',
lines[9])
! call assert_equal('',
lines[10])
call delete('Xprofile_file.vim')
call delete('Xprofile_file.log')
--- 152,168
let lines = readfile('Xprofile_file.log')
call assert_equal(11, len(lines))
! call assert_match('^SCRIPT .*Xprofile_file.vim$', lines[0])
! call assert_equal('Sourced 1 time', lines[1])
! call assert_match('^Total time:\s\+\d\+\.\d\+$',lines[2])
! call assert_match('^ Self time:\s\+\d\+\.\d\+$',lines[3])
! call assert_equal('', lines[4])
! call assert_equal('count total (s) self (s)',lines[5])
! call assert_match('1 0.\d\+ echo "hello', lines[6])
! call assert_equal(' \ world"', lines[7])
! call assert_match('1 0.\d\+ echo "foo ', lines[8])
! call assert_equal(' \bar"',lines[9])
! call assert_equal('', lines[10])
call delete('Xprofile_file.vim')
call delete('Xprofile_file.log')
***
*** 221,224
--- 221,294
call delete('Xprofile_file.vim')
call delete('Xprofile_file.log')
+ endfunc
+
+ func Test_profdel_func()
+ let lines = [
+ \ 'profile start Xprofile_file.log',
+ \ 'func! Foo1()',
+ \ 'endfunc',
+ \ 'func! Foo2()',
+ \ 'endfunc',
+ \ 'func! Foo3()',
+ \ 'endfunc',
+ \ '',
+ \ 'profile func Foo1',
+ \ 'profile func Foo2',
+ \ 'call Foo1()',
+ \ 'call Foo2()',
+ \ '',
+ \ 'profile func Foo3',
+ \ 'profdel func Foo2',
+ \ 'profdel func Foo3',
+ \ 'call Foo1()',
+ \ 'call Foo2()',
+ \ 'call Foo3()' ]
+ call writefile(lines, 'Xprofile_file.vim')
+ call system(v:progpath . ' -es --clean -c "so Xprofile_file.vim" -c q')
+ call assert_equal(0, v:shell_error)
+
+ let lines = readfile('Xprofile_file.log')
+ call assert_equal(24, len(lines))
+
+ " Check that:
+ " - Foo1() is called twice (profdel not invoked)
+ " - Foo2() is called once (profdel invoked after it was called)
+ " - Foo3() is not called (profdel invoked before it was called)
+ call assert_equal('FUNCTION Foo1()', lines[0])
+ call
Re: Trying to build with MinGW
Hi Bram, 2018/6/30 Sat 23:14:33 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > > > Does it make sense to require WINVER 0x0600 here while 0x501 is the > > > default above? Doesn't it mean the binary won't work properly on > > > Windows XP anyway? Then we might as well make 0x0600 the default. And > > > add a comment to use 0x0501 for XP, and the need to disable using > > > iscygpty. > > > > I set up iscygpty to use dynamic loading so that it can be executed on XP. > > Even though, it uses some definitions for Vista APIs, therefore it requires > > WINVER=0x0600. This doesn't affect other parts of Vim, so we can use other > > value for the default of WINVER (if needed). > > My point is that as it is now it doesn't build. So we should probably > make 0x0600 the default. > > > > > For the other problem, I think your MinGW is too old. (The above problem > > > > should be caused by the same reason, though.) > > > > I highly recommend you to use MinGW-w64 instead of the original MinGW > > > > (which > > > > looks dead). > > > > > > I ran the installer to update, but it appears nothing happened. > > > > > > > There are some distributions which provide binary packages of MinGW-w64, > > > > and I think MSYS2 is the best. (https://www.msys2.org/) > > > > > > > > If we still need to support the original MinGW, we might need some > > > > modifications to the codes and makefiles. However, I can't help it, > > > > because I have already uninstalled the original MinGW. > > > > > > I think the main use of MinGW is to build without MSVC. And since it's > > > freely available there shouldn't be much problem getting the latest > > > version. > > > > > > So how about updating the instructions to add a step-by-step > > > explanation how to build Vim with MinGW? Including hints how to get the > > > latest version (and possibly deleting the old one, if that is needed). > > > > Okay, we might need a step-by-step instruction how to setup MSYS2 for > > building Vim. The msys2 installer just installs a basic environment. > > Each user need to install GCC and other development packages by using > > the `pacman` command. > > > > > > # Setup msys2 environment for building Vim > > > > 1. Setup the basic msys2 environment > > > > Go to the official page of MSYS2: https://www.msys2.org > > Download an installer: > > > > * msys2-x86_64-MMDD.exe for 64-bit Windows > > (Even if you want to build 32-bit Vim) > > * msys2-i686-MMDD.exe for 32-bit Windows > > > > Follow the official instructions to update basic packages. Execute > > `pacman -Syu` and restart MSYS2 window (select "MSYS2 MSYS" icon from the > > Start Menu), then execute `pacman -Su`. > > If pacman complains that `catgets` and `libcatgets` conflict with another > > package, select `y` to remove them. > > > > 2. Install additional packages for building Vim > > > > The following package groups are required for building Vim: > > > > * base-devel > > * mingw-w64-i686-toolchain (for building 32-bit Vim) > > * mingw-w64-x86_64-toolchain (for building 64-bit Vim) > > > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the > > following > > command to install them: > > > > pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain > > > > Or you can use the `pacboy` command to avoid long package names: > > > > pacboy -S base-devel: toolchain:m > > This asks what packages to install. Should this install "all"? > It installs an awful lot of stuff, it says it uses 1.5 Gbyte. > My laptop is almost full... If you only want to build 32-bit Vim, you don't need to install the x86_64 toolchain. In this case, you can use one of the following commands: pacman -S base-devel mingw-w64-i686-toolchain or: pacboy -S base-devel: toolchain:i (The ":i" suffix means i686 only.) If you only want to build 64-bit Vim, you don't need to install the i686 toolchain. In this case, you can use one of the following commands: pacman -S base-devel mingw-w64-x86_64-toolchain or: pacboy -S base-devel: toolchain:x (The ":x" suffix means x86_64 only.) Some of the package might not be needed for building Vim, but I haven't checked which is necessary and which is not. The above package groups are generally useful for building many kind of programs. > > (See `pacboy help` for the help.) > > > > 3. Keep the build environment up-to-date > > > > After you have installed the build environment, you may want to keep it > > up-to-date (E.g. always use the latest GCC). > > In that case, you just need to execute the command `pacman -Syu` once or > > twice. > > > > > > # Build Vim > > > > Select one of the following icon from the Start Menu: > > > > * MSYS2 MinGW 32-bit (To build 32-bit versions of Vim) > > * MSYS2 MinGW 64-bit (To build 64-bit versions of Vim) > > > > Go to the source directory of Vim, then execute the make command. E.g.: > > > > make -f Make_mingw.mak GUI=yes > > Hmm, I get "make:
Patch 8.1.0130
Patch 8.1.0130
Problem:":profdel func" does not work if func was called already.
(Dominique Pelle)
Solution: Reset uf_profiling and add a flag to indicate initialization was
done.
Files: src/structs.h, src/userfunc.c
*** ../vim-8.1.0129/src/structs.h 2018-06-23 19:22:45.614486258 +0200
--- src/structs.h 2018-06-30 18:12:48.678664711 +0200
***
*** 1345,1350
--- 1345,1351
garray_T uf_lines; /* function lines */
#ifdef FEAT_PROFILE
int uf_profiling; /* TRUE when func is being profiled */
+ int uf_prof_initialized;
/* profiling the function as a whole */
int uf_tm_count;/* nr of calls */
proftime_Tuf_tm_total;/* time spent in function + children */
*** ../vim-8.1.0129/src/userfunc.c 2018-05-22 18:31:30.001365739 +0200
--- src/userfunc.c 2018-06-30 18:20:15.704075693 +0200
***
*** 293,302
fp->uf_scoped = NULL;
#ifdef FEAT_PROFILE
- fp->uf_tml_count = NULL;
- fp->uf_tml_total = NULL;
- fp->uf_tml_self = NULL;
- fp->uf_profiling = FALSE;
if (prof_def_func())
func_do_profile(fp);
#endif
--- 293,298
***
*** 706,711
--- 702,708
#ifdef FEAT_PROFILE
proftime_Twait_start;
proftime_Tcall_start;
+ int started_profiling = FALSE;
#endif
/* If depth of calling is getting too high, don't execute the function */
***
*** 921,927
--- 918,927
if (do_profiling == PROF_YES)
{
if (!fp->uf_profiling && has_profiling(FALSE, fp->uf_name, NULL))
+ {
+ started_profiling = TRUE;
func_do_profile(fp);
+ }
if (fp->uf_profiling
|| (fc->caller != NULL && fc->caller->func->uf_profiling))
{
***
*** 965,970
--- 965,973
profile_add(>caller->func->uf_tm_children, _start);
profile_add(>caller->func->uf_tml_children, _start);
}
+ if (started_profiling)
+ // make a ":profdel func" stop profiling the function
+ fp->uf_profiling = FALSE;
}
#endif
***
*** 2522,2544
{
int len = fp->uf_lines.ga_len;
! if (len == 0)
! len = 1; /* avoid getting error for allocating zero bytes */
! fp->uf_tm_count = 0;
! profile_zero(>uf_tm_self);
! profile_zero(>uf_tm_total);
! if (fp->uf_tml_count == NULL)
! fp->uf_tml_count = (int *)alloc_clear((unsigned) (sizeof(int) * len));
! if (fp->uf_tml_total == NULL)
! fp->uf_tml_total = (proftime_T *)alloc_clear((unsigned)
! (sizeof(proftime_T) * len));
! if (fp->uf_tml_self == NULL)
! fp->uf_tml_self = (proftime_T *)alloc_clear((unsigned)
! (sizeof(proftime_T) * len));
! fp->uf_tml_idx = -1;
! if (fp->uf_tml_count == NULL || fp->uf_tml_total == NULL
! || fp->uf_tml_self == NULL)
! return; /* out of memory */
fp->uf_profiling = TRUE;
}
--- 2525,2552
{
int len = fp->uf_lines.ga_len;
! if (!fp->uf_prof_initialized)
! {
! if (len == 0)
! len = 1; /* avoid getting error for allocating zero bytes */
! fp->uf_tm_count = 0;
! profile_zero(>uf_tm_self);
! profile_zero(>uf_tm_total);
! if (fp->uf_tml_count == NULL)
! fp->uf_tml_count = (int *)alloc_clear(
! (unsigned)(sizeof(int) * len));
! if (fp->uf_tml_total == NULL)
! fp->uf_tml_total = (proftime_T *)alloc_clear(
!(unsigned)(sizeof(proftime_T) * len));
! if (fp->uf_tml_self == NULL)
! fp->uf_tml_self = (proftime_T *)alloc_clear(
!(unsigned)(sizeof(proftime_T) * len));
! fp->uf_tml_idx = -1;
! if (fp->uf_tml_count == NULL || fp->uf_tml_total == NULL
! || fp->uf_tml_self == NULL)
! return; /* out of memory */
! fp->uf_prof_initialized = TRUE;
! }
fp->uf_profiling = TRUE;
}
***
*** 2568,2574
{
--todo;
fp = HI2UF(hi);
! if (fp->uf_profiling)
{
if (sorttab != NULL)
sorttab[st_len++] = fp;
--- 2576,2582
{
--todo;
fp = HI2UF(hi);
! if (fp->uf_prof_initialized)
{
if (sorttab != NULL)
sorttab[st_len++] = fp;
*** ../vim-8.1.0129/src/version.c 2018-06-30 17:09:23.039956879 +0200
--- src/version.c 2018-06-30 18:12:14.990860555 +0200
Patch 8.1.0129
Patch 8.1.0129
Problem:Still some xterm-like terminals get a stray "p" on startup.
Solution: Consider all terminals that reply with a version smaller than 95
as not an xterm. (James McCoy)
Files: src/term.c
*** ../vim-8.1.0128/src/term.c 2018-05-23 20:30:52.738566360 +0200
--- src/term.c 2018-06-30 17:02:55.602235946 +0200
***
*** 4690,4695
--- 4690,4700
&& STRNCMP(tp + extra - 2, "0;115;0c", 8) == 0)
is_not_xterm = TRUE;
+ // Xterm first responded to this request at patch level
+ // 95, so assume anything below 95 is not xterm.
+ if (version < 95)
+ is_not_xterm = TRUE;
+
/* Only request the cursor style if t_SH and t_RS are
* set. Only supported properly by xterm since version
* 279 (otherwise it returns 0x18).
*** ../vim-8.1.0128/src/version.c 2018-06-30 17:09:12.656017847 +0200
--- src/version.c 2018-06-30 17:04:03.133837926 +0200
***
*** 791,792
--- 791,794
{ /* Add new patch number below this line */
+ /**/
+ 129,
/**/
--
hundred-and-one symptoms of being an internet addict:
147. You finally give up smoking...because it made the monitor dirty.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 8.1.0128
Patch 8.1.0128 Problem:Building with MinGW does not work out-of-the-box. Solution: Add instructions for MSYS2. Set default WINVER. Add batch files to set $PATH for MSYS2. Files: src/Make_cyg_ming.mak, src/INSTALLpc.txt, src/msys32.bat, src/msys64.bat, Filelist *** ../vim-8.1.0127/src/Make_cyg_ming.mak 2018-06-19 18:58:04.006489842 +0200 --- src/Make_cyg_ming.mak 2018-06-30 15:56:42.425768825 +0200 *** *** 75,83 # Set to yes to enable OLE support. OLE=no ! # Set the default $(WINVER) to make it work with WinXP. ifndef WINVER ! WINVER = 0x0501 endif # Set to yes to enable Cscope support. --- 75,84 # Set to yes to enable OLE support. OLE=no ! # Set the default $(WINVER). Use 0x0501 to make it work with WinXP. ifndef WINVER ! # WINVER = 0x0501 ! WINVER = 0x0600 endif # Set to yes to enable Cscope support. *** ../vim-8.1.0127/src/INSTALLpc.txt 2017-12-14 13:07:27.0 +0100 --- src/INSTALLpc.txt 2018-06-30 16:08:36.949674031 +0200 *** *** 22,44 Contents: 1. Microsoft Visual C++ ! 2. Using MinGW ! 3. Cygwin ! 4. Borland ! 5. Cross compiling for Win32 from a Linux machine ! 6. Building with Python support ! 7. Building with Python3 support ! 8. Building with Racket or MzScheme support ! 9. Building with Lua support ! 10. Building with Perl support ! 11. Building with Ruby support ! 12. Building with Tcl support ! 13. Building with Terminal support ! 14. Building with DirectX (DirectWrite) support ! 15. Windows 3.1 ! 16. MS-DOS ! 17. Installing after building from sources The currently recommended way (that means it has been verified to work) is --- 22,45 Contents: 1. Microsoft Visual C++ ! 2. Using MSYS2 with MinGW ! 3. Using MinGW ! 4. Cygwin ! 5. Borland ! 6. Cross compiling for Win32 from a Linux machine ! 7. Building with Python support ! 8. Building with Python3 support ! 9. Building with Racket or MzScheme support ! 10. Building with Lua support ! 11. Building with Perl support ! 12. Building with Ruby support ! 13. Building with Tcl support ! 14. Building with Terminal support ! 15. Building with DirectX (DirectWrite) support ! 16. Windows 3.1 ! 17. MS-DOS ! 18. Installing after building from sources The currently recommended way (that means it has been verified to work) is *** *** 261,268 http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/default.aspx ! 2. MinGW (written by Ron Aaron: ) --- 262,348 http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/default.aspx + 2. MSYS2 with MinGW + === ! 2.1. Setup the basic msys2 environment ! ! Go to the official page of MSYS2: https://www.msys2.org ! Download an installer: ! ! * msys2-x86_64-MMDD.exe for 64-bit Windows ! (Even if you want to build 32-bit Vim) ! * msys2-i686-MMDD.exe for 32-bit Windows ! ! Execute the installer and follow the instructions to update basic packages. ! At the end keep the checkbox checked to run msys2 now. If needed, you can ! open the window from the start menu, MSYS2 64 bit / MSYS2 MSYS ! ! Execute: ! $ pacman -Syu ! ! And restart MSYS2 window (select "MSYS2 MSYS" icon from the Start Menu). ! Then execute: ! $ pacman -Su ! ! If pacman complains that `catgets` and `libcatgets` conflict with another ! package, select `y` to remove them. ! ! ! 2.2. Install additional packages for building Vim ! ! The following package groups are required for building Vim: ! ! * base-devel ! * mingw-w64-i686-toolchain (for building 32-bit Vim) ! * mingw-w64-x86_64-toolchain (for building 64-bit Vim) ! ! Use the following command to install them: ! ! $ pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain ! ! Or you can use the `pacboy` command to avoid long package names: ! ! $ pacboy -S base-devel: toolchain:m ! ! (See `pacboy help` for the help.) ! ! ! 2.3. Keep the build environment up-to-date ! ! After you have installed the build environment, you may want to keep it ! up-to-date (E.g. always use the latest GCC). ! In that case, you just need to execute the command: ! $ pacman -Syu ! ! ! # Build Vim ! ! Select one of the following icon from the Start Menu: ! ! * MSYS2 MinGW 32-bit (To build 32-bit versions of Vim) ! * MSYS2 MinGW 64-bit (To build 64-bit versions of Vim) ! ! Go to the source directory of Vim, then execute the make command. E.g.: ! ! make -f Make_ming.mak ! make -f Make_ming.mak GUI=no ! make -f Make_ming.mak GUI=no DEBUG=yes ! ! NOTE: you can't execute the vim.exe in the MSYS console, open a normal Windows ! console for that. You need to set $PATH to be able to build there, e.g.: ! ! set PATH=c:\msys64\mingw32\bin;c:\msys64\usr\bin;%PATH% ! ! This command is in msys32.bat. Or or the 64 bit compiler use msys64.bat: ! ! set
Re: Trying to build with MinGW
Ken Takata wrote: > > Does it make sense to require WINVER 0x0600 here while 0x501 is the > > default above? Doesn't it mean the binary won't work properly on > > Windows XP anyway? Then we might as well make 0x0600 the default. And > > add a comment to use 0x0501 for XP, and the need to disable using > > iscygpty. > > I set up iscygpty to use dynamic loading so that it can be executed on XP. > Even though, it uses some definitions for Vista APIs, therefore it requires > WINVER=0x0600. This doesn't affect other parts of Vim, so we can use other > value for the default of WINVER (if needed). My point is that as it is now it doesn't build. So we should probably make 0x0600 the default. > > > For the other problem, I think your MinGW is too old. (The above problem > > > should be caused by the same reason, though.) > > > I highly recommend you to use MinGW-w64 instead of the original MinGW > > > (which > > > looks dead). > > > > I ran the installer to update, but it appears nothing happened. > > > > > There are some distributions which provide binary packages of MinGW-w64, > > > and I think MSYS2 is the best. (https://www.msys2.org/) > > > > > > If we still need to support the original MinGW, we might need some > > > modifications to the codes and makefiles. However, I can't help it, > > > because I have already uninstalled the original MinGW. > > > > I think the main use of MinGW is to build without MSVC. And since it's > > freely available there shouldn't be much problem getting the latest > > version. > > > > So how about updating the instructions to add a step-by-step > > explanation how to build Vim with MinGW? Including hints how to get the > > latest version (and possibly deleting the old one, if that is needed). > > Okay, we might need a step-by-step instruction how to setup MSYS2 for > building Vim. The msys2 installer just installs a basic environment. > Each user need to install GCC and other development packages by using > the `pacman` command. > > > # Setup msys2 environment for building Vim > > 1. Setup the basic msys2 environment > > Go to the official page of MSYS2: https://www.msys2.org > Download an installer: > > * msys2-x86_64-MMDD.exe for 64-bit Windows > (Even if you want to build 32-bit Vim) > * msys2-i686-MMDD.exe for 32-bit Windows > > Follow the official instructions to update basic packages. Execute > `pacman -Syu` and restart MSYS2 window (select "MSYS2 MSYS" icon from the > Start Menu), then execute `pacman -Su`. > If pacman complains that `catgets` and `libcatgets` conflict with another > package, select `y` to remove them. > > 2. Install additional packages for building Vim > > The following package groups are required for building Vim: > > * base-devel > * mingw-w64-i686-toolchain (for building 32-bit Vim) > * mingw-w64-x86_64-toolchain (for building 64-bit Vim) > > Open the "MSYS2 MSYS" icon from the Start Menu, then you can use the following > command to install them: > > pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain > > Or you can use the `pacboy` command to avoid long package names: > > pacboy -S base-devel: toolchain:m This asks what packages to install. Should this install "all"? It installs an awful lot of stuff, it says it uses 1.5 Gbyte. My laptop is almost full... > (See `pacboy help` for the help.) > > 3. Keep the build environment up-to-date > > After you have installed the build environment, you may want to keep it > up-to-date (E.g. always use the latest GCC). > In that case, you just need to execute the command `pacman -Syu` once or > twice. > > > # Build Vim > > Select one of the following icon from the Start Menu: > > * MSYS2 MinGW 32-bit (To build 32-bit versions of Vim) > * MSYS2 MinGW 64-bit (To build 64-bit versions of Vim) > > Go to the source directory of Vim, then execute the make command. E.g.: > > make -f Make_mingw.mak GUI=yes Hmm, I get "make: command not found". I guess I should have selected "all" when using pacboy. That uses the MSYS console, where just about nothing works. "git pull" doesn't work. Can't even run the Vim I just build in it. How to build Vim in a normal Windows console? I tried prepending "c:\msys64\usr\bin" to $PATH and that appears to work. No wait, that picks up an old MinGW version of gcc. OK, this seems to work: also prepend c:\msys64\mingw32\bin". I'll make a patch with these hints, we can further improve it afterwards. -- hundred-and-one symptoms of being an internet addict: 144. You eagerly await the update of the "Cool Site of the Day." /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not
