Hi, lists.
asin() is missing after adding assert*() because their definitions table is
not sorted.
diff --git a/src/eval.c b/src/eval.c
index ef0ea5e..2668f3d 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -8073,11 +8073,13 @@ static struct fst
{"argidx", 0, 0, f_argidx},
{"arglisti
Hi, lists.
asin() is missing after adding assert*() because their definitions table is
not sorted.
diff --git a/src/eval.c b/src/eval.c
index ef0ea5e..2668f3d 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -8073,11 +8073,13 @@ static struct fst
{"argidx", 0, 0, f_argidx},
{"arglisti
Hi lists.
The asin() is missing because the definitions list is not sorted.
diff --git a/src/eval.c b/src/eval.c
index ef0ea5e..2668f3d 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -8073,11 +8073,13 @@ static struct fst
{"argidx", 0, 0, f_argidx},
{"arglistid", 0, 2, f_argli
I confirm the bug: In gvim 7.4.970 (Huge):
:echo asin(1.0)
E117: unknown function: asin
E15: Invalid expression: asin(1.0)
Command-line completion _does_ complete asi to asin(
Best regards,
Tony.
On Sun, Dec 13, 2015 at 10:46 AM, watiko wrote:
> Hi lists.
>
> The asin() is missing because the
Hi, lists.
asin() is missing after adding assert*() because their definitions table is
not sorted.
diff --git a/src/eval.c b/src/eval.c
index ef0ea5e..2668f3d 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -8073,11 +8073,13 @@ static struct fst
{"argidx", 0, 0, f_argidx},
{"arglisti
Hi all,
VS2015 is raising a pointer cast truncation warning in gui_w32.c On
64bit builds with VC HandleToLong() is a function but for 32bit builds
it is a macro. The current VIM code defines a macro if one is not
defined so shadows the function call resulting in the warning.
Going through
2015-12-13 13:23 GMT+03:00 Tony Mechelynck :
> I confirm the bug: In gvim 7.4.970 (Huge):
>
> :echo asin(1.0)
> E117: unknown function: asin
> E15: Invalid expression: asin(1.0)
>
> Command-line completion _does_ complete asi to asin(
>
> Best regards,
> Tony.
>
> On Sun, Dec 13, 2015 at 10:46 AM,
Patch 7.4.971
Problem:The asin() function can't be used.
Solution: Sort the function table properly. (Watiko)
Files: src/eval.c
*** ../vim-7.4.970/src/eval.c 2015-12-03 16:32:52.720051790 +0100
--- src/eval.c 2015-12-13 14:42:32.888940088 +0100
***
*** 8073,8083
Tux wrote:
> Bram Moolenaar schrob am Samstag, 12. Dezember 2015 um 21:32 Zeit:
>
> > I'm thinking about it. Especially for MS-Windows, the version provided
> > from the ftp site is quite old.
>
> Why not just add a link to up-to-date third-party builds (like mine,
> cough)?
The few times I l
Watiko wrote:
[not sure why I got 4 copies of this]
> The asin() is missing because the definitions list is not sorted.
Thanks!
--
hundred-and-one symptoms of being an internet addict:
257. Your "hundred-and-one" lists include well over 101 items, since you
automatically interpret all n
Bram Moolenaar schrob am Sonntag, 13. Dezember 2015 um 14:45 Zeit:
> If I look at https://tuxproject.de/projects/vim/ I don't see that
> button. In fact I don't know how to download. Perhaps you can redo
> that page. I would expect a nice big download button, with an
> explanation of what is in
Christian Brabandt wrote:
> here is a patch, that fixes a memory leak in option.c
Thanks. But it needs an #ifdef.
--
hundred-and-one symptoms of being an internet addict:
259. When you enter your name in the AltaVista search engine, the top ten
matches do indeed refer to you.
/// Bram
Patch 7.4.972
Problem:Memory leak when there is an error in setting an option.
Solution: Free the saved value (Christian Brabandt)
Files: src/option.c
*** ../vim-7.4.971/src/option.c 2015-12-11 22:38:32.655594654 +0100
--- src/option.c2015-12-13 14:55:36.212414185 +0100
**
Hi,
GVimEXT fails to build for me with VS2015, a large number of undefined
symbols from the Windows headers when compiling. The Makefile is
missing some symbols defined that Win32.mak needs to set up the build
environment correctly.
I have tested the following patch with a VS2015 64bit and
Hi Bram,
Attached is a patch to update runtime/syntax/objc.vim.
This update includes new syntax/highlight support for
- type information of collection classes such as NSArray and NSDictionary.
- type specifiers and property attributes as to nullability.
Broadly speaking, this update covers the
Tux wrote:
> Bram Moolenaar schrob am Sonntag, 13. Dezember 2015 um 14:45 Zeit:
>
> > If I look at https://tuxproject.de/projects/vim/ I don't see that
> > button. In fact I don't know how to download. Perhaps you can redo
> > that page. I would expect a nice big download button, with an
> >
Bram Moolenaar schrob am Sonntag, 13. Dezember 2015 um 17:33 Zeit:
> These are 7zip files. I don't think 7zip is included with the Windows
> distribution. And then how to unpack? The text says it's an archive,
> not an installer. A self-installing executable is what most users
> prefer.
You'r
Kazunobu Kuriyama wrote:
> Hi Bram,
>
> Attached is a patch to update runtime/syntax/objc.vim.
>
> This update includes new syntax/highlight support for
>
> - type information of collection classes such as NSArray and NSDictionary.
> - type specifiers and property attributes as to nullability.
Bram,
since 7.4.530 the address has a different meaning for certain commands.
I am not sure, if it makes sense, to adjust the address for folded
lines, if the address type is not of type ADDR_LINES. This might be
unexpected, see e.g. here https://vi.stackexchange.com/questions/5810
So here is
Hi, lists.
Problem:
call assert_false(1)
then we expected v:errors is
[" line 0: Expected False but got 1"]
but actual value is
[" line 0: Expected False but got 1"]
diff --git src/eval.c src/eval.c
index 2668f3d..81dc478 100644
--- src/eval.c
+++ src/eval.c
@@ -9183,10 +9183,13 @@ fill_assert_e
Thanks Christian for the excellent gn added in 7.3.610. However,
using Vim 7.4.972 I'm seeing this problem with cgn after search.
Put the cursor at beginning of line:
abc x def x ghi x jkl
Type /x and press Enter to find first x.
Type cgn"x" and press Esc to replace search hit with "x" (three
c
The same double space applies to assert_true() but not to
assert_equal(), for instance:
:let v:errors = []
:call assert_equal(1,2)
:echo v:errors
[' line 0: expected 1 but got 2']
with an unexpected space at the very start but only one space between
1 and but, and none after 2.
IMHO this whole qu
Thank you for follow-up, Tony.
>with an unexpected space at the very start but only one space between
>1 and but, and none after 2.
Yes, I knew that such behavior. And I also think the leading space is
unecpected.
additional patch:
diff --git src/eval.c src/eval.c
index 81dc478..fd2f74c 10064
23 matches
Mail list logo