Re: Bug with function()
Am 2016-09-13 23:15, schrieb Bram Moolenaar:
Christian Brabandt wrote:
Bram,
I think this is a bug:
:echo function('tr')
-> returns tr
:echo function('tr()')
-> errors: E475: Invalid argument: [NULL]
0
You mean that it says NULL? That can be fixed.
Yes, I meant the NULL. That error message is not really helpful.
Best,
Christian
--
--
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.
[doc][patch] Fix version8.txt
Hi,
I found some typos in version8.txt.
And I also found inconsistency (or mistakes) in some contributor names.
E.g.:
* Lcd, lcd47, etc.
* Nikolai Pavlov, Nikolay Pavlov (Does he prefer ZyX?)
* ZyX, Zyx
* Jürgen Krämer, Jurgen Kramer
* Jun Takimoto, Jun T.
* Shougo Matsu, Shougo
* Dominique Pelle, Dominique
etc.
(Sorry if I am misunderstanding.)
At least, the following two are obvious mistakes:
--- a/runtime/doc/version8.txt
+++ b/runtime/doc/version8.txt
@@ -4311,7 +4311,7 @@ Files:src/misc2.c
Patch 7.4.650
Problem:Configure check may fail because the dl library is not used.
-Solution: Put "-ldl" in LIBS rather than LDFLAGS. (Oazki Kiichi)
+Solution: Put "-ldl" in LIBS rather than LDFLAGS. (Ozaki Kiichi)
Files: src/configure.in, src/auto/configure
Patch 7.4.651 (after 7.4.582)
@@ -14405,7 +14409,7 @@ Solution: Don't access curwin when exi
Files: src/buffer.c
Patch 7.4.2349
-Problem:Valgrind reports using uninitialzed memory. (Dominique Pelle)
+Problem:Valgrind reports using uninitialized memory. (Dominique Pelle)
Solution: Check the length before checking for a NUL.
Files: src/message.c
I found them when I tried to create patch contributor ranking ;-)
https://gist.github.com/k-takata/628ff1103f92b9135041a15c43c85b32
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.
# HG changeset patch
# Parent 8b043df15b502fff5aef0533e1b1d7efbd1ce2ad
diff --git a/runtime/doc/version8.txt b/runtime/doc/version8.txt
--- a/runtime/doc/version8.txt
+++ b/runtime/doc/version8.txt
@@ -498,7 +498,7 @@ Files: src/search.c
Patch 7.4.006
Problem:mkdir("foo/bar/", "p") gives an error message. (David Barnett)
-Solution: Remove the trailing slash. (lcd)
+Solution: Remove the trailing slash. (Lcd)
Files: src/eval.c
Patch 7.4.007
@@ -521,7 +521,7 @@ Files: src/fileio.c
Patch 7.4.010 (after 7.4.006)
Problem:Crash with invalid argument to mkdir().
-Solution: Check for empty string. (lcd47)
+Solution: Check for empty string. (Lcd)
Files: src/eval.c
Patch 7.4.011
@@ -1031,7 +1031,7 @@ Files: src/configure.in, src/auto/co
Patch 7.4.095 (after 7.4.093)
Problem:Regexp for LuaJIT version doesn't work on BSD.
-Solution: Use "*" instead of "\+" and "\?". (Ozaki)
+Solution: Use "*" instead of "\+" and "\?". (Ozaki Kiichi)
Files: src/configure.in, src/auto/configure
Patch 7.4.096
@@ -1176,7 +1176,7 @@ Solution: Fix various problems. (Samue
Files: src/os_unix.c, src/os_unix.h, src/os_vms.c
Patch 7.4.120 (after 7.4.117)
-Problem:Can't build with Perl 5.18 on Linux. (Lcd 47)
+Problem:Can't build with Perl 5.18 on Linux. (Lcd)
Solution: Add #ifdef. (Ken Takata)
Files: src/if_perl.xs
@@ -1750,7 +1750,7 @@ Files: src/Makefile
Patch 7.4.218
Problem:It's not easy to remove duplicates from a list.
-Solution: Add the uniq() function. (LCD)
+Solution: Add the uniq() function. (Lcd)
Files: runtime/doc/change.txt, runtime/doc/eval.txt,
runtime/doc/usr_41.txt, runtime/doc/version7.txt, src/eval.c,
src/testdir/test55.in, src/testdir/test55.ok
@@ -3347,7 +3347,7 @@ Files: src/getchar.c
Patch 7.4.486
Problem:Check for writing to a yank register is wrong.
-Solution: Negate the check. (Zyx). Also clean up the #ifdefs.
+Solution: Negate the check. (ZyX). Also clean up the #ifdefs.
Files: src/ex_docmd.c, src/ex_cmds.h
Patch 7.4.487
@@ -4311,7 +4311,7 @@ Files: src/misc2.c
Patch 7.4.650
Problem:Configure check may fail because the dl library is not used.
-Solution: Put "-ldl" in LIBS rather than LDFLAGS. (Oazki Kiichi)
+Solution: Put "-ldl" in LIBS rather than LDFLAGS. (Ozaki Kiichi)
Files: src/configure.in, src/auto/configure
Patch 7.4.651 (after 7.4.582)
@@ -4903,7 +4903,7 @@ Solution: Make the buffer larger. (Kaz
Files: src/eval.c
Patch 7.4.749 (after 7.4.741)
-Problem:For some options two consecutive commas are OK. (Nikolay Pavlov)
+Problem:For some options two consecutive commas are OK. (Nikolai Pavlov)
Solution: Add the P_ONECOMMA flag.
Files: src/option.c
@@ -5454,7 +5454,7 @@ Files: src/search.c
Patch 7.4.840 (after 7.4.829)
Problem:Tooltip window stays open.
-Solution: Send a WM_CLOSE message. (Jurgen Kramer)
+Solution: Send a WM_CLOSE message. (Jürgen Krämer)
Files: src/gui_w32.c
Patch 7.4.841
@@ -5464,7 +5464,7 @@ Files: src/option.c
Patch 7.4.842 (after 7.4.840)
Problem:Sending too many messages to close the
Re: gvim and ASCII glyphs
On Tuesday, 13 September 2016 23:21:01 UTC+1, mcepl wrote: > On 2016-08-08, 12:50 GMT, Tony Mechelynck wrote: > > You should see, in that order, the glyphs for ff fi fl ft st > > ffi ffl. > > I absolutely don't like them (in the monospaced fonts that > > have them; in serif or sans-serif fonts it's different, > > especially in serif italic). OTOH, I think that expanding them > > to two or three character cells would be ugly the opposite > > way. > > It could be the problem with your font. I use > https://github.com/tonsky/FiraCode/ and it seems to work for me > just fine. > > Matěj > > -- > https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz > GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > > May you come to the attention of those in authority. > May you find what you are looking for. > May you live in interesting times. >-- claimed to be a Chinese proverb, but its origin is disputed > first documented use > Frederic R. Coudert, Proceedings of the Academy of Political Science, > 1939 Hi, glad to see that people give it a try. You may want to use the updated version of the patch here: https://github.com/manuelschiller/vim/commit/0c8d6a735f1f6452b11c0da039f8c9c9f125475a It allows users to hand-tune for which characters they want to bypass the glyph cache by putting a line in .vimrc, e.g. let g:gtk_nocache=[0x, 0xfc00, 0xf801, 0x7801] This contains a bitmap for each character < 128, which has the corresponding bit set if the glyph cache is to be bypassed (which in turn enables ligatures). The default is no ligatures, unless people set something like above in their .vimrc. With this slightly more sophisticated patch, people have the option to enable/disable certain ligatures by routing the corresponding characters through the cache (or not) without recompiling, if they so prefer. Comments remain welcome! Cheers, Manuel -- -- 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: gvim and ASCII glyphs
2016-09-14 6:09 GMT+09:00 Matěj Cepl : > On 2016-08-11, 15:40 GMT, Kazunobu Kuriyama wrote: > >> Screenshot attached. (I haven't try PragmataPro.) > > > > I don't either for an obvious reason..Isn't there a free version? :) > > Would https://github.com/tonsky/FiraCode/ work? > > Matěj > Thank you for the note. I've already installed it on my Mac. I personally think it useful for rendering tests because of its wider coverage of ligature glyphs in comparison other free ligature fonts. > > -- > https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz > GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > > ..every Man has a Property in his own Person. This no Body has > any Right to but himself. The Labour of his Body, and the Work of > his Hands, we may say, are properly his. The great and chief > end therefore, of Mens uniting into Commonwealths, and putting > themselves under Government, is the Preservation of their > Property. > -- John Locke, "A Treatise Concerning Civil Government" > > -- > -- > 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. > -- -- 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: [doc][patch] Fix version8.txt
Ken Takata wrote: > Hi, > > I found some typos in version8.txt. > And I also found inconsistency (or mistakes) in some contributor names. > E.g.: > > * Lcd, lcd47, etc. > * Nikolai Pavlov, Nikolay Pavlov (Does he prefer ZyX?) > * ZyX, Zyx > * Jürgen Krämer, Jurgen Kramer > * Jun Takimoto, Jun T. > * Shougo Matsu, Shougo > * Dominique Pelle, Dominique > etc. > (Sorry if I am misunderstanding.) A few more inconsistencies. I'm not 100% sure about all them without taking the time to check who submitted each patch, but most certainly the following are the same persons: - Ben Fritz, Benjamin Fritz, Fritzophrenic - Bjorn Linse, Björn Linse - Cade Forester, Cade Foster - Charles, Charles Campbell - Christian J. Robinson, Christian Robinson - Ramel, Ramel Eshed - Yegappan, Yegappan Lakshmanan Regards Dominique -- -- 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.
[bug] new undo blocks are not created for each repeated call of :diffput using @: or a mapping
In Vim version 7.4.2066 When repeating the command :diffput using @: or a mapping containing :diffput each change to the buffer that is being put to is lumped into one big undo block. I would expect that either of the uses of indirect calls to :diffput would produce a new undo block like repeating of :diffget with @: does. I did notice that the expected behavior is achieved if you navigate to the buffer being put to after each indirect :diffput call. Mapping Example: nnoremap dp :execute 'diffput' -- -- 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: [doc][patch] Fix version8.txt
On Mi, 14 Sep 2016, Ken Takata wrote: > I found them when I tried to create patch contributor ranking ;-) > https://gist.github.com/k-takata/628ff1103f92b9135041a15c43c85b32 Interesting read, thanks! Best, Christian -- Frage an Radio Eriwan: "Ist es wahr, daß der liebe Gott Parteigenosse werden kann?" Antwort: "Im Prinzip ja, nur müsste er vorher aus der Kirche austreten." -- -- 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: [vim/vim] Optimize HiDPI Screen on GVim Windows (#1059)
On Wednesday, September 14, 2016 at 2:41:42 PM UTC-4, nor...@googlegroups.com wrote: > I am not sure, what you are seeing, probably some kind of this: > dcpurton/regfont#1 > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub Yep,was an issue with my font.Fixed 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 --- 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: gvim and ASCII glyphs
On 2016-09-14, 13:28 GMT, manuelschiller.pimail via vim_dev wrote: > It allows users to hand-tune for which characters they want to > bypass the glyph cache by putting a line in .vimrc, e.g. > > let g:gtk_nocache=[0x, 0xfc00, 0xf801, 0x7801] > > This contains a bitmap for each character < 128, which has the > corresponding bit set if the glyph cache is to be bypassed > (which in turn enables ligatures). The default is no > ligatures, unless people set something like above in their > .vimrc. With this slightly more sophisticated patch, people > have the option to enable/disable certain ligatures by routing > the corresponding characters through the cache (or not) > without recompiling, if they so prefer. So, for example how to make >= and <= be included so that they translate into (glyphs from :digraphs): =< ≤ 8804 >= ≥ 8805 Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 The first mistake in publick business, is the going into it. -- Benjamin Franklin -- -- 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: Possible problem when running a job immediately followed by a sleep
Santiago Agüero wrote:
> The script's output is being used as a way to check for any syntax error,
> it should print (and it is, in bash):
>
> /bin/sh errors.sh
> errors.sh: line 5: syntax error near unexpected token `newline'
> errors.sh: line 5: `foo('
>
> And yes, the job exits quickly, in fact, if you use a short sleep (ie:
> sleep 1m) it works, not all the times, though.
>
> I've been looking at the ch_logfile messages and got:
>
> - RubJob # works
>
> 133.807009 : Starting job: /bin/sh errors.sh
> 133.807064 on 8: Created channel
> 133.807414 on 7: Freeing job
> 133.807501 : looking for messages on channels
> 133.807506 on 7: Closing channel
> 133.807508 on 7: Clearing channel
> 133.807511 on 7: Freeing channel
> 133.807534 : looking for messages on channels
> 133.808933 RECV on 8: 'errors.sh: line 5: syntax error near unexpected
> token `newline'
> errors.sh: line 5: `foo('
> '
> 133.808941 on 8: Invoking channel callback HandlerCallback
> 133.809058 on 8: Invoking channel callback HandlerCallback
> 133.809108 ERR on 8: channel_select_check(): Cannot read from channel, will
> close it soon
> 133.809112 : looking for messages on channels
> 133.809114 on 8: Closing channel because of previous read error
> 133.809116 on 8: Closing channel
> 133.809122 on 8: Invoking callbacks before closing
> 133.809124 on 8: Invoking close callback HandlerClose
> 134.309137 : looking for messages on channels
> 144.312764 on 8: Job ended
>
> - RunJob | sleep 50m # doesn't work
>
> 151.694974 : Starting job: /bin/sh errors.sh
> 151.695013 on 9: Created channel
> 151.695387 on 8: Freeing job
> 151.745598 ERR on 9: channel_select_check(): Cannot read from channel, will
> close it soon
> 151.745623 : looking for messages on channels
> 151.745628 on 9: Closing channel because of previous read error
> 151.745631 on 9: Closing channel
> 151.745650 on 9: Invoking callbacks before closing
> 151.745655 on 9: Invoking close callback HandlerClose
> 151.745764 on 8: Closing channel
> 151.745767 on 8: Clearing channel
> 151.745771 on 8: Freeing channel
> 151.745792 : looking for messages on channels
> 162.255837 on 9: Job ended
Thanks, this is useful. Now we need to find out why we see an error or
nothing to read, while reading the pipe/socket should give us the
output. Adding some ch_logs() calls in channel_wait() could help
pinpoint it.
--
MAN: You don't frighten us, English pig-dog! Go and boil your bottoms,
son of a silly person. I blow my nose on you, so-called Arthur-king,
you and your silly English K...kaniggets.
He puts hands to his ears and blows a raspberry.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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: [doc][patch] Fix version8.txt
Ken Takata wrote: > I found some typos in version8.txt. > And I also found inconsistency (or mistakes) in some contributor names. > E.g.: > > * Lcd, lcd47, etc. > * Nikolai Pavlov, Nikolay Pavlov (Does he prefer ZyX?) > * ZyX, Zyx > * Jürgen Krämer, Jurgen Kramer > * Jun Takimoto, Jun T. > * Shougo Matsu, Shougo > * Dominique Pelle, Dominique > etc. > (Sorry if I am misunderstanding.) > > > At least, the following two are obvious mistakes: Thanks, I included most of them. -- In war we're tough and able. Quite indefatigable Between our quests We sequin vests And impersonate Clark Gable It's a busy life in Camelot. I have to push the pram a lot. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// 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: gvim and ASCII glyphs
On 2016-09-14, 13:28 GMT, manuelschiller.pimail via vim_dev wrote: > It allows users to hand-tune for which characters they want to > bypass the glyph cache by putting a line in .vimrc, e.g. > > let g:gtk_nocache=[0x, 0xfc00, 0xf801, 0x7801] Tell me, please, you have never ever considered this variable to be anything more than a cludge during the development? Please, tell me you never planned to inflict this on users (yes, I know, vim users are not normal humans, but still)! Please. Could you also add value of the variable which would be equivalent of the previous patch, please? I really don’t know how to make it work as well as the previous one? Otherwise, vim with your new patch builds on RHEL-7 without problem http://koji.fedoraproject.org/koji/taskinfo?taskID=15633602 Thank you, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 It is a rare mind indeed that can render the hitherto non-existent blindingly obvious. The cry “I could have thought of that” is a very popular and misleading one, for the fact is that they didn’t, and a very significant and revealing fact it is too. -- Douglas Adams, Dirk Gently's Holistic Detective Agency -- -- 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: gvim and ASCII glyphs
Hi, On Mi, 14 Sep 2016, manuelschiller.pimail via vim_dev wrote: > > let g:gtk_nocache=[0x, 0xfc00, 0xf801, 0x7801] > > This contains a bitmap for each character < 128, which has the > corresponding bit set if the glyph cache is to be bypassed (which in > turn enables ligatures). The default is no ligatures, unless people > set something like above in their .vimrc. With this slightly more > sophisticated patch, people have the option to enable/disable certain > ligatures by routing the corresponding characters through the cache > (or not) without recompiling, if they so prefer. > > Comments remain welcome! I appreciate your effort you put into this. But for the hell of it, I can't understand how the values inside g:gtk_nocache are supposed to work. Can you please describe more in detail, what each value stands for? I am afraid this needs some documentation and possibly a different format. We don't have something similar like this. Perhaps a new type for the 'renderoptions'? Best, Christian -- Ich habe etliche mal bemerkt, daß ich Kopf-Weh bekam, wenn ich mich lange in einem Hohl-Spiegel betrachtete. -- Georg Christoph Lichtenberg -- -- 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: [vim/vim] Static analysis report (#1049)
On So, 11 Sep 2016, Christian Brabandt wrote: > On Fr, 09 Sep 2016, Yegappan Lakshmanan wrote: > > > Hi Christian, > > > > On Fri, Sep 9, 2016 at 12:08 AM, Christian Brabandt > > wrote: > > > How did you create that report? > > > > > > > I use the following steps to run static analysis using the clang > > static analyzer (http://clang-analyzer.llvm.org/) > > > > $ scan-build -o /tmp/vim_report ./configure --with-features=huge > > $ scan-build -o /tmp/vim_report make > > Would it make sense, to run something like this regularly? I can setup a cronjob to build Vim regularly and push the report to somewhere. But someone has to look at it... I have similar cronjobs already for coverity. But that one notifies us, when something changes. Best, Christian -- Woher soll ich wissen, was ich denke, bevor ich lese, was ich schreibe? -- -- 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.0.0004
Patch 8.0.0004
Problem:A string argument for function() that is not a function name
results in an error message with NULL. (Christian Brabandt)
Solution: Use the argument for the error message.
Files: src/evalfunc.c, src/testdir/test_expr.vim
*** ../vim-8.0.0003/src/evalfunc.c 2016-09-10 13:39:30.0 +0200
--- src/evalfunc.c 2016-09-13 23:04:02.917786784 +0200
***
*** 3612,3618
if (s == NULL || *s == NUL || (use_string && VIM_ISDIGIT(*s))
|| (is_funcref && trans_name == NULL))
! EMSG2(_(e_invarg2), s);
/* Don't check an autoload name for existence here. */
else if (trans_name != NULL && (is_funcref
? find_func(trans_name) == NULL
--- 3612,3618
if (s == NULL || *s == NUL || (use_string && VIM_ISDIGIT(*s))
|| (is_funcref && trans_name == NULL))
! EMSG2(_(e_invarg2), use_string ? get_tv_string(&argvars[0]) : s);
/* Don't check an autoload name for existence here. */
else if (trans_name != NULL && (is_funcref
? find_func(trans_name) == NULL
*** ../vim-8.0.0003/src/testdir/test_expr.vim 2016-09-04 21:41:26.0
+0200
--- src/testdir/test_expr.vim 2016-09-13 23:03:20.426385157 +0200
***
*** 439,444
--- 439,447
let s:fref = function(s:f)
call assert_equal(v:t_string, s:fref('x'))
call assert_fails("call function('s:f')", 'E700:')
+
+ call assert_fails("call function('foo()')", 'E475:')
+ call assert_fails("call function('foo()')", 'foo()')
endfunc
func Test_funcref()
*** ../vim-8.0.0003/src/version.c 2016-09-12 19:51:07.689659657 +0200
--- src/version.c 2016-09-14 22:06:19.364036465 +0200
***
*** 766,767
--- 766,769
{ /* Add new patch number below this line */
+ /**/
+ 4,
/**/
--
A KNIGHT rides into shot and hacks him to the ground. He rides off.
We stay for a moment on the glade. A MIDDLE-AGED LADY in a C. & A.
twin-set emerges from the trees and looks in horror at the body of her
HUSBAND.
MRS HISTORIAN: FRANK!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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.
exists() result sometimes misleading for a command
exists() result is sometimes misleading for a command.
Example (with GTK3 gvim linked with GTK 3.16.7):
:echo exists(':tearoff')
2
:tearoff &Help
E319: Sorry, the command is not available in this version
So for example the following code in my vimrc would produce the exact
error which it is meant to avoid:
au GUIEnter * if exists(':tearoff') == 2 | exe 'tearoff &Help' | endif
If the :tearoff command is disabled in GTK3 gvim, then IMHO
exists(':tearoff') ought to return 0, not 2.
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.
gx doesn't work anymore with vim 8.0.4
I'm using vim 8.0.4 on Windows 7 compiled with MinGW. When doing gx on an url I get: E117: Unknown function: netrw#CheckIfRemote E116: Invalid arguments for function netrw#BrowseX 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 --- 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.
