Hello!
A user of one of my plugins recently reported this error: `E117: Unknown
function: gettabvar`. He also told me the version of Vim he's using.
How can I find out when gettabvar() – or any function in general – was added to
VimL?
Being able to find this out would help me decide whether
On Wed, January 15, 2014 09:59, b...@airbladesoftware.com wrote:
Hello!
A user of one of my plugins recently reported this error: `E117: Unknown
function: gettabvar`. He also told me the version of Vim he's using.
How can I find out when gettabvar() – or any function in general – was
added
On 15 January 2014 10:13, Christian Brabandt cbli...@256bit.org wrote:
On Wed, January 15, 2014 09:59, b...@airbladesoftware.com wrote:
Hello!
A user of one of my plugins recently reported this error: `E117: Unknown
function: gettabvar`. He also told me the version of Vim he's using.
How
On 15 Jan 2014, at 10:17, Lech Lorens lech.lor...@gmail.com wrote:
Easy: have a look at the VSC log. I'm using git. Just started gitk
and searched for gettabvar() and then scrolled up to find the nearest
tag. This can also be done with a little bit of command line magic.
This works for me:
On 15-Jan-2014 09:59 +0100, boss wrote:
Hello!
A user of one of my plugins recently reported this error: `E117:
Unknown function: gettabvar`. He also told me the version of Vim he's
using.
How can I find out when gettabvar() – or any function in general – was
added to VimL?
Being
Yasuhiro Matsumoto wrote:
:echo 0 foo#bar()
Shouldn't eval foo#bar, I think.
diff -r a42040fed96c src/eval.c
--- a/src/eval.c Tue Jan 14 21:31:34 2014 +0100
+++ b/src/eval.c Wed Jan 15 12:33:09 2014 +0900
@@ -5159,7 +5159,7 @@
{
/* If s is the name
Tony Mechelynck wrote:
On 14/01/14 19:36, Bram Moolenaar wrote:
Patch 7.4.153
Problem:Compiler warning for pointer type.
Solution: Add type cast.
Files: src/if_py_both.h, src/if_python.c, src/if_python3.c
I get the following warnings when compiling Vim 7.4.155
On 15 Jan 2014, at 10:58, Ingo Karkat sw...@ingo-karkat.de wrote:
Note that instead of checking for the version in the guard (which
usually involves also checking the patch level), it's easier and better
to check for the existence, in your case via if exists('*gettabvar') ...
See :h exists().
That's an existing problem, right?
Perhaps there are other similar situations.
Yes, but Yukihiro's patch can solve this issue. :)
--
--
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
On mar, 2014-01-14 at 18:26 +0100, Lech Lorens wrote:
Some comments:
Hi Lech,
Thank for your feedback. See my comments below and the updated patches.
1. You are not following the Vim coding convention everywhere: opening and
closing braces on their own lines.
Done.
2. How about
Yukihiro Nakadaira wrote:
On Wed, Jan 15, 2014 at 3:44 AM, Bram Moolenaar b...@moolenaar.net wrote:
Yukihiro Nakadaira wrote:
Patch 7.4.149
Problem:Get E685 error when assigning a function to an autoload
variable.
(Yukihiro Nakadaira)
Solution:
On Tue, Dec 31, 2013 at 6:54 PM, Bram Moolenaar b...@moolenaar.net wrote:
Yukihiro Nakadaira wrote:
After patch 7.4.045, substitute('xxx', 'x\zs', 'y', 'g') returns xyxxy.
xyxyxy is expected.
Thanks for reporting the problem. I'll add it in the todo list.
I think that this problem can
Thiago,
I would love this to work and I thank you for your effort, but I'm quite
doubtful that vgetc can be safely run in a background thread. It simply does
too much work. Just to pick one example, it appears to be responsible for
blinking the GUI cursor while it's waiting, which will
Vim devs,
I have discovered a bug which affects at least 7.4.135 and (likely) 7.3.547.
Example file is available at
https://mega.co.nz/#!ndVjXZTY!aMX_9ll-0ce861tQwNZBaFveb_kONCJxvAT2GZOvzlc
(1.2MB in size) which will crash vim when attempting the following regex:
:%s/\n//g
The file contains
On Wednesday, January 15, 2014 4:44:34 AM UTC-6, Ashley Hewson wrote:
Thiago,
I would love this to work and I thank you for your effort, but I'm quite
doubtful that vgetc can be safely run in a background thread. It simply does
too much work. Just to pick one example, it appears to be
On Wed, Jan 15, 2014 at 11:44 AM, Ben Fritz fritzophre...@gmail.com wrote:
I thought the idea of this patch, was to allow background threads to send Vim
a message, that says when you get a chance, run function X. Then, at some
later point in time, when Vim is not busy, it will run function X
On Wednesday, January 15, 2014 10:08:53 AM UTC-6, Thiago Arruda wrote:
Ashley, its possible that a 'DeferredCall' message arrives while
the background thread is in the middle of running 'vgetc'. A DeferredCall will
invoke a vimscript function and then will update the screen which might
Comment #2 on issue 193 by chrisbr...@googlemail.com: Insert in Visual mode
gives wrong result
http://code.google.com/p/vim/issues/detail?id=193
This is to be expected, since C-gu set's the '[ mark and that confuses
Vim. I don't see a way how to fix this currently, besides setting another
On Wed, Jan 15, 2014 at 2:23 PM, Ben Fritz fritzophre...@gmail.com wrote:
So, your background thread is directly calling a function to get user
input/update the screen? I think THAT is a mistake. This should not happen. A
background thread can be used for data processing, but any user input,
Yukihiro Nakadaira wrote:
On Tue, Dec 31, 2013 at 6:54 PM, Bram Moolenaar b...@moolenaar.net wrote:
Yukihiro Nakadaira wrote:
After patch 7.4.045, substitute('xxx', 'x\zs', 'y', 'g') returns xyxxy.
xyxyxy is expected.
Thanks for reporting the problem. I'll add it in the todo
Comment #3 on issue 193 by dominiqu...@gmail.com: Insert in Visual mode
gives wrong result
http://code.google.com/p/vim/issues/detail?id=193
Christian wrote:
This is to be expected, since C-gu set's the '[ mark and
that confuses Vim. I don't see a way how to fix this currently,
besides
Hi,
There is any command so that I can convert all the VHDL keywords into CAPS ?
Thanks and regards
Chethan M
Ph:9739388444
--
--
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
Hello,
When running vim inside ConEmu, although lazyredraw is OFF (nolazydraw),
I still find the need to hit Ctrl-L or execute :redraw! (with
shriek) to clear up the screen that has been messed-up by some bug with
using Vim inside ConEmu (
23 matches
Mail list logo
