Hi!
On Thu, Apr 24, 2014 at 12:43:01PM +0200, Bram Moolenaar wrote:
> > Me, too. The following used to work:
> >
> > fun! Foo()
> > endfun
> > let g:Foo = function('Foo')
> >
> > After 7.4.264, I get:
> > " E705: Variable name conflicts with existing function: g:Foo
>
> That is corr
Comment #3 on issue 217 by coryom...@gmail.com: Cannot compile vim 7.4.238+
with Linux kernel version <= 2.6.36 due to addition of smack support.
http://code.google.com/p/vim/issues/detail?id=217
Looks like this is fixed in 7.4.254.
--
You received this message because this project is config
On 24/04/2014 10:46 a.m., Ben Fritz wrote:
> On Thursday, April 24, 2014 10:23:51 AM UTC-5, Cesar wrote:
>> I'm using vim 7.3.264 on Windows 7.
>>
>> ...
>>
>> If I do for example ':14tabf file' it always finds the first version...
>>
>> It used to work with older vim versions.
>
> Did you actuall
> > E121: Undefined variable: g:vundle_last_status
> > E15: Invalid expression: 'error' == g:vundle_last_status
>
> These might be the result of another error, causing the variables not
> being set.
I've never had any problems before patch 260. since there was a discussion
going on that patch, I
Matteo Cavalleri wrote:
> > > Patch 7.4.264 (after 7.4.260)
> > > Problem:Can't define a function starting with "g:". Can't assign a
> > > funcref to a buffer-local variable.
> > > Solution: Skip "g:" at the start of a function name. Don't check for
> > > colons
> > > when as
On Thursday, April 24, 2014 10:23:51 AM UTC-5, Cesar wrote:
> I'm using vim 7.3.264 on Windows 7.
>
> ...
>
> If I do for example ':14tabf file' it always finds the first version...
>
> It used to work with older vim versions.
Did you actually mean 7.4.264 rather than 7.3, or are you actually u
I'm using vim 7.3.264 on Windows 7.
'[count]find file' works fine. If I do, for example ':2find file'
it finds the correct version of file, and if I do ':3find file' it
outputs the message 'E347: No more file "file" found in path' what it is
correct and expected, but with '[count]tabfind' it does
Patch 7.4.265 (after 7.4.260)
Problem:Can't call a global function with "g:" in an expression.
Solution: Skip the "g:" when looking up the function.
Files: src/eval.c, src/testdir/test_eval.in, src/testdir/test_eval.ok
*** ../vim-7.4.264/src/eval.c 2014-04-23 20:43:07.290689167 +020
Ingo Karkat wrote:
> What I find inconsistent and strange is that though I can define
> g:Foo(), I cannot call it with that global-scoped name:
>
> fun g:Foo()
> return 42
> endfun
> echo Foo()
> 42
> echo g:Foo()
> E117: Unknown function: g:Foo
> E15: Invalid e
On 24-Apr-2014 14:27 +0200, Christian Brabandt wrote:
> Am 2014-04-24 13:39, schrieb Ingo Karkat:
>> Hello Vim developers,
>>
>> my plugins' automated test suite found another regression. When
>> reformatting lines with gq{motion}, the start of change mark '[ does not
>> point to the start of the
Am 2014-04-24 13:39, schrieb Ingo Karkat:
Hello Vim developers,
my plugins' automated test suite found another regression. When
reformatting lines with gq{motion}, the start of change mark '[ does
not
point to the start of the first line [0, lnum, 1, 0] any more, but
instead to after the end o
Am 2014-04-24 10:27, schrieb unam3:
How to reproduce:
Create file with the content below, place cursor at first "}" or
at "{" and try
to jump from one to other.
var s = function(){
//{qwe
}
I think, this is more or less an use case for the matchit plugin. Read
:h matchit fo
How to reproduce:
Create file with the content below, place cursor at first "}" or
at "{" and try
to jump from one to other.
var s = function(){
//{qwe
}
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are r
Hello Vim developers,
my plugins' automated test suite found another regression. When
reformatting lines with gq{motion}, the start of change mark '[ does not
point to the start of the first line [0, lnum, 1, 0] any more, but
instead to after the end of the original first line [0, lnum,
len(getlin
On 24-Apr-2014 12:43 +0200, Bram Moolenaar wrote:
> Ingo Karkat wrote:
>
>> Me, too. The following used to work:
>>
>> fun! Foo()
>> endfun
>> let g:Foo = function('Foo')
>>
>> After 7.4.264, I get:
>> " E705: Variable name conflicts with existing function: g:Foo
>
> That is correct.
Ingo Karkat wrote:
> Me, too. The following used to work:
>
> fun! Foo()
> endfun
> let g:Foo = function('Foo')
>
> After 7.4.264, I get:
> " E705: Variable name conflicts with existing function: g:Foo
That is correct. Previously Foo() and g:Foo were different names, which
is wron
On 23-Apr-2014 18:49 +0200, Bram Moolenaar wrote:
> Patch 7.4.261
> Problem:When updating the window involves a regexp pattern, an interactive
> substitute to replace a "\n" with a line break fails. (Ingo
> Karkat)
> Solution: Set reg_line_lbr in vim_regsub() and vim_regs
On 23-Apr-2014 23:11 +0200, Matteo Cavalleri wrote:
>>> Patch 7.4.264 (after 7.4.260)
>>
>>> Problem:Can't define a function starting with "g:". Can't assign a
>>
>>> funcref to a buffer-local variable.
>>
>>> Solution: Skip "g:" at the start of a function name. Don't check for
>>
18 matches
Mail list logo
