> There is. The very good probability of such bugs is one of the reasons why I
> did not even consider adding similar global in extended funcref patch when I
> encountered similar problems (and removed no_autoload from there once it got
> my attention).
This patch replaces global with arguments
> Thank you for finding it out. I didn't notice it.
>
> Perhaps there is another problem that exists('x[y#z()]') doesn't trigger
> autoload.
There is. The very good probability of such bugs is one of the reasons why I
did not even consider adding similar global in extended funcref patch when I
On Tue, Jan 7, 2014 at 5:33 AM, ZyX wrote:
> > Yes, I am.
>
> You should not be.
>
> let d={}
> echo exists('*d[extend(g:, {"Foo#x": function("tr")})]')
>
> . f_exists() sets no_autoload to TRUE, dict_extend() runs
> var_check_func_name() which you have modified setting it back to FALSE
>
> Yes, I am.
You should not be.
let d={}
echo exists('*d[extend(g:, {"Foo#x": function("tr")})]')
. f_exists() sets no_autoload to TRUE, dict_extend() runs var_check_func_name()
which you have modified setting it back to FALSE before f_exists ends. f_exists
should by the way save no_au
On Sun, Jan 5, 2014 at 11:44 PM, Nikolay Pavlov wrote:
>
> On Jan 1, 2014 9:47 AM, "Yukihiro Nakadaira"
> wrote:
> >
> > Steps to reproduce:
> > $ cat ~/.vim/autoload/Foo.vim
> > let Foo#x = 0
> > $ vim -u NONE -N
> > :let Foo#
On Jan 1, 2014 9:47 AM, "Yukihiro Nakadaira"
wrote:
>
> Steps to reproduce:
> $ cat ~/.vim/autoload/Foo.vim
> let Foo#x = 0
> $ vim -u NONE -N
> :let Foo#x = function('tr')
> E685: Internal error: hash_add()
>
> eval.c:set_var()
> -&g
Yukihiro -
> Steps to reproduce:
> $ cat ~/.vim/autoload/Foo.vim
> let Foo#x = 0
> $ vim -u NONE -N
> :let Foo#x = function('tr')
> E685: Internal error: hash_add()
>
> eval.c:set_var()
> -> var_check_func_name()Foo.vim is load
Steps to reproduce:
$ cat ~/.vim/autoload/Foo.vim
let Foo#x = 0
$ vim -u NONE -N
:let Foo#x = function('tr')
E685: Internal error: hash_add()
eval.c:set_var()
-> var_check_func_name()Foo.vim is loaded and Foo#x is created.
-> hash_add() error,
ts = taglist('.')
: echomsg "called taglist()"
:catch
: echomsg "catched" v:exception
: " The {results} are never assigned.
:endtry
calling taglist()
catched Vim(call):E685: Internal error: hash_add()
Or did I miss another way to do this? By the way, thanks fo
On 09-Jun-2010 Peter Odding wrote:
> Bram Moolenaar wrote:
> >Ah! when I do this on the Vim source tags file I can actually reproduce
> >it! I'll put this in the todo list.
[...]
> Since you mentioned you can reproduce the problem (and I just saw a
> mail by Lech Lorens stating the same) I guess
Bram Moolenaar wrote:
Well, first save that tags file, generating it again may get rid of the
problem and we won't be able to reproduce it.
I already put the buggy tags file in a TAR to be sure I wouldn't
accidentally modify it. And the problem did indeed go away after
modifying the tags file
On 08-Jun-2010 Bram Moolenaar wrote:
>
> Well, first save that tags file, generating it again may get rid of the
> problem and we won't be able to reproduce it.
>
> It's trange, hash tables are used a lot, it's unlikely that hash_add()
> itself is wrong. Perhaps memory got corrupted somehow?
>
h I've never seen before:
>
> easytags.vim: Vim(let):E685: Internal error: hash_add() (at function
> easytags#autoload..easytags#highlight_cmd, line 4)
>
> When I looked up :help E685 I found the following:
>
> This is an internal error. If you can reproduce it, pl
s.vim: Vim(let):E685: Internal error: hash_add() (at function
easytags#autoload..easytags#highlight_cmd, line 4)
When I looked up :help E685 I found the following:
This is an internal error. If you can reproduce it, please send in a
bug report.
The good news is that reproducing the E685
14 matches
Mail list logo
