Re: [bug] use of free memory in win_getid(...)

Dominique Pellé wrote: > afl-fuzz found this case which causes vim-8.0.81 and > older to use free memory: > > $ cat >use-free-mem.vim < tabedit X > tabfirst > copen > only > echo win_getid(1, 1) > EOF > > $ valgrind vim -u NONE -S use-free-mem.vim -cqa 2> vg.log > > And vg.log contains: > >

[bug] use of free memory, regression introduced by Vim-7.4.1980

-14.04, so it's a regression. Doing a bissection, I see that: Vim-7.4.1980 has the BUG Vim-7.4.1979 is OK So bug is introduced by Vim-7.4.1980: === commit 361c8f0e517e41f1f1d34dae328044406fde80ac Author: Bram Moolenaar <b...@vim.org> Date: Sat Jul 2 15:41:47 2016 +0200 patch 7.4.1980

[bug] use of free memory in win_getid(...)

Hi afl-fuzz found this case which causes vim-8.0.81 and older to use free memory: $ cat >use-free-mem.vim < vg.log And vg.log contains: ==11501== Memcheck, a memory error detector ==11501== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==11501== Using Valgrind-3.12.0.SVN and

[bug] GVim freezes when moving the scrollbar

Vim version: 7.4 (installed using apt-get) GUI: GTK+3 OS: Trisquel 7.0 (Ubuntu 14.04 equivalent) Settings: All default (except that syntax highlighting is enabled) Description: When I use the mouse to move the left/right vertical scrollbar with syntax highlighting enabled, the editor freezes.

Re: [bug][patch] matchaddpos() may not draw overldapped pos.

Hirohito Higashi wrote: > 2016-10-15(Sat) 3:41:58 UTC+9 Bram Moolenaar: > > Ozaki Kiichi wrote: > > > > > This is matchaddpos() problem. > > > > > > [repro steps] > > > > > > vim -Nu NONE > > > > > > i1234567890 > > > :call matchaddpos('ErrorMsg', [[1, 1, 5], [1, 3, 5]]) > > > > > >

Re: [bug][patch] matchaddpos() may not draw overldapped pos.

Hi Bram and Kiichi, 2016-10-15(Sat) 3:41:58 UTC+9 Bram Moolenaar: > Ozaki Kiichi wrote: > > > This is matchaddpos() problem. > > > > [repro steps] > > > > vim -Nu NONE > > > > i1234567890 > > :call matchaddpos('ErrorMsg', [[1, 1, 5], [1, 3, 5]]) > > > > expected: colored 1~7 ("12345" and

Re: [bug][patch] matchaddpos() may not draw overldapped pos.

Ozaki Kiichi wrote: > This is matchaddpos() problem. > > [repro steps] > > vim -Nu NONE > > i1234567890 > :call matchaddpos('ErrorMsg', [[1, 1, 5], [1, 3, 5]]) > > expected: colored 1~7 ("12345" and "34567"; pos [1, 1, 5] and [1, 3, 5], > overlapped "345") > > actual: colored 1~5 ("12345";

Re: [bug][patch] Doing ":redraw" during external command causes strange screen state

Ozaki Kiichi wrote: > > Isn't this a bit too drastic? When termcap_active it should still be > > possible to output text (e.g. from another timer command). > > > > Also check msg_use_printf(). Looks like your change overrules its own > > check for termcap_active. > > Hmm, yes. I think we

Re: [bug][patch] Doing ":redraw" during external command causes strange screen state

> Isn't this a bit too drastic? When termcap_active it should still be > possible to output text (e.g. from another timer command). > > Also check msg_use_printf(). Looks like your change overrules its own > check for termcap_active. Hmm, yes. I think we should suppress updating screen while

Re: [bug][patch] Doing ":redraw" during external command causes strange screen state

Ozaki Kiichi wrote: > Doing ":redraw" during external command causes strange screen state and > cursor position. > > [repro steps] > > test.vim > > > " for clarity of screen state > colorscheme morning > syntax on > > function! Callback(timer) abort > redraw > "quit >

[bug][patch] matchaddpos() may not draw overldapped pos.

Hi. This is matchaddpos() problem. [repro steps] vim -Nu NONE i1234567890 :call matchaddpos('ErrorMsg', [[1, 1, 5], [1, 3, 5]]) expected: colored 1~7 ("12345" and "34567"; pos [1, 1, 5] and [1, 3, 5], overlapped "345") actual: colored 1~5 ("12345"; only first pos [1, 1, 5]) This problem

[bug][patch] Doing ":redraw" during external command causes strange screen state

Hi. Doing ":redraw" during external command causes strange screen state and cursor position. [repro steps] test.vim " for clarity of screen state colorscheme morning syntax on function! Callback(timer) abort redraw "quit endfunction call timer_start(1000, 'Callback') :!ls

Re: conflicts with in windows console vim (vim.exe), bug ?

Marius Gedminas wrote： > > After downloading msys2 and installing gcc, ncurses-devel ... with pacman, > > I started to build latest vim inside msys2, and found these: > > > > checking for tgetent in -ltinfo... (cached) no > > checking for tgetent in -lncurses... (cached) yes > > ncurses library

Re: Bug: - not taken to be stdin if -- is provided

an option, it actually isn't (see > > > > http://lists.gnu.org/archive/html/bug-coreutils/2016-10/msg2.html > > ). > > (...) > > > > > > If "vim -- -" reads from stdin, then how do you edit a file name "-"? > > > The current behavi

Re: Bug: - not taken to be stdin if -- is provided

2016-10-05 8:18 GMT+09:00 João Miguel <jmcf...@openmailbox.org>: > A 2016-10-04T22:49:10 +0200, Bram Moolenaar escreveu: > > > > João Miguel wrote: > > > > > While I thought "-" was an option, it actually isn't (see > > > http://lists.g

Re: Bug: - not taken to be stdin if -- is provided

A 2016-10-04T22:49:10 +0200, Bram Moolenaar escreveu: > > João Miguel wrote: > > > While I thought "-" was an option, it actually isn't (see > > http://lists.gnu.org/archive/html/bug-coreutils/2016-10/msg2.html). (...) > > If "vim -- -" rea

Re: Bug: - not taken to be stdin if -- is provided

João Miguel wrote: > While I thought "-" was an option, it actually isn't (see > http://lists.gnu.org/archive/html/bug-coreutils/2016-10/msg2.html). > It seems POSIX simply specifies that if the argument provided is "-", > stdin should be read. So "

Bug: - not taken to be stdin if -- is provided

Hello, While I thought "-" was an option, it actually isn't (see http://lists.gnu.org/archive/html/bug-coreutils/2016-10/msg2.html). It seems POSIX simply specifies that if the argument provided is "-", stdin should be read. So "vim -- -" should do th

Re: [bug] lambda expressions

Ken Takata wrote: > > How about this: > > > > If {expr2} is a |Funcref| it must take two arguments: > > 1. the key or the index of the current item. > > 2. the value of the current item. > > The function must return |TRUE| if the

Re: [bug] lambda expressions

ristian, > > > > > > > > > > 2016/9/21 Wed 5:31:26 UTC+9 Christian Brabandt wrote: > > > > >> Hi, > > > > >> I think I found a bug with lambda expressions. > > > > >> > > > > >> I was looking int

Re: conflicts with in windows console vim (vim.exe), bug ?

On Fri, Sep 23, 2016 at 12:41:56AM -0700, skywind3000 wrote: > Magnus Woldrich： > > >Thanks, very disappointted with cmd.exe > > > > Here you go: https://msys2.github.io/ > > After downloading msys2 and installing gcc, ncurses-devel ... with pacman, > I started to build latest vim inside msys2,

Re: conflicts with in windows console vim (vim.exe), bug ?

Magnus Woldrich： > >Thanks, very disappointted with cmd.exe > > Here you go: https://msys2.github.io/ After downloading msys2 and installing gcc, ncurses-devel ... with pacman, I started to build latest vim inside msys2, and found these: checking for tgetent in -ltinfo... (cached) no checking

Re: [bug] lambda expressions

Ken Takata wrote: > 2016/9/22 Thu 2:37:29 UTC+9 Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > > > Am 2016-09-21 00:00, schrieb Ken Takata: > > > > Hi Christian, > > > > > > > > 2016/9/21 Wed 5:31:26 UTC+9 Christian

Re: conflicts with in windows console vim (vim.exe), bug ?

Thanks, very disappointted with cmd.exe Here you go: https://msys2.github.io/ -- -- 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

Re: conflicts with in windows console vim (vim.exe), bug ?

onsole vim, mapping will cause unable to > > work properly (it appears that backspace also get mapped), > > > > After reading a lot of docs, I still can't figure out how to fix it . > > > > Is that a bug ? or something misconfiguration ? > > > > Ca

Re: [bug] lambda expressions

Hi Bram, 2016/9/22 Thu 2:37:29 UTC+9 Bram Moolenaar wrote: > Christian Brabandt wrote: > > > Am 2016-09-21 00:00, schrieb Ken Takata: > > > Hi Christian, > > > > > > 2016/9/21 Wed 5:31:26 UTC+9 Christian Brabandt wrote: > > >> Hi, &

Re: conflicts with in windows console vim (vim.exe), bug ?

ork properly (it appears that backspace also get mapped), > > After reading a lot of docs, I still can't figure out how to fix it . > > Is that a bug ? or something misconfiguration ? > > Can console behave exactly in the same way like other platforms ? , the ASCII charact

conflicts with in windows console vim (vim.exe), bug ?

still can't figure out how to fix it . Is that a bug ? or something misconfiguration ? Can console behave exactly in the same way like other platforms ? -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to

Re: [bug] lambda expressions

Christian Brabandt wrote: > Am 2016-09-21 00:00, schrieb Ken Takata: > > Hi Christian, > > > > 2016/9/21 Wed 5:31:26 UTC+9 Christian Brabandt wrote: > >> Hi, > >> I think I found a bug with lambda expressions. > >> > >> I was lookin

Re: [bug] lambda expressions

Am 2016-09-21 00:00, schrieb Ken Takata: Hi Christian, 2016/9/21 Wed 5:31:26 UTC+9 Christian Brabandt wrote: Hi, I think I found a bug with lambda expressions. I was looking into writing some automated tests and was trying to use the new lambda expressions. However this does not work

Re: [bug] lambda expressions

Hi Christian, 2016/9/21 Wed 5:31:26 UTC+9 Christian Brabandt wrote: > Hi, > I think I found a bug with lambda expressions. > > I was looking into writing some automated tests and was trying to use > the new lambda expressions. However this does not work as expected: > &g

[bug] lambda expressions

Hi, I think I found a bug with lambda expressions. I was looking into writing some automated tests and was trying to use the new lambda expressions. However this does not work as expected: Here is an example: #v+ let a = ['FOOBAR"word"', 'FOOBAR"word2"'] let

[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

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

Re: Bug with function()

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. -- Women are probably the main cause

Bug with function()

Bram, I think this is a bug: :echo function('tr') -> returns tr :echo function('tr()') -> errors: E475: Invalid argument: [NULL] 0 Best, Christian -- Jeder glaubt gern, was er wünscht, die Dinge aber sind oft anders beschaffen. -- Demosthenes -- -- You received this m

Re: [bug] Problem with regexpengine 1 and /\%d0

by the old RE engine as it outputs "Switching to > backtracking RE engine for pattern [\u0]\+" And when manually setting > re=2, both patterns work. > > I think this is a bug, but haven't had time to investigate this yet (and > I cannot share the data file). I could no

[bug] access beyond end of string in findmatchlimit in vim-7.4.2358

Hi Here is one more bug found by afl-fuzz using vim-7.4.2358. Vim-7.4.52 in xubuntu-14.04 also has the bug so it's an old bug: $ cat <bug.vim norm oa norm oabcd) norm v= q! EOF $ valgrind --num-callers=30 vim -u NONE -i NONE -S bug.vim 2>log $ cat log ==4689== Memcheck, a memory error de

Re: [bug] access beyond end of string when doing search with /

Dominique wrote: > afl-fuzz found a bug in vim-7.4.2354 and older. > Default vim in xubuntu-14.04 (vim-7.4.52) also has > the bug, so it's an old bug. > > $ cat <bug.vim > func X() > s/^/a/ > / > endfunc > call X() > q! > EOF > > $ valgrind --nu

[bug] access beyond end of string when doing search with /

Hi afl-fuzz found a bug in vim-7.4.2354 and older. Default vim in xubuntu-14.04 (vim-7.4.52) also has the bug, so it's an old bug. $ cat <bug.vim func X() s/^/a/ / endfunc call X() q! EOF $ valgrind --num-callers=30 vim -u NONE -i NONE -S bug.vim 2>log And log file contains: =

Re: [bug] read heap overflow in do_pending_operator()

Dominique Pellé wrote: > Hi > > Here is one more bug found by afl-fuzz in vim-7.4.2330 > an older: > > $ cat bug.vim > new > call append(0, [" a", "b"]) > norm kVdggViw > bw! > %d > > $ valgrind --num-callers=20 vim -u NONE -S bug.vim -c

Re: YML formatting inconsistent bug

Am 2016-09-08 14:28, schrieb Kai Hendry: Bizarrely 7.4.2334 seems to fix the issue. I did report the issue to the script writers but they never responded btw. Surely in future Github is a better bet? https://github.com/vim/vim/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20yml For runtime

Re: YML formatting inconsistent bug

Bizarrely 7.4.2334 seems to fix the issue. I did report the issue to the script writers but they never responded btw. Surely in future Github is a better bet? https://github.com/vim/vim/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20yml -- -- You received this message from the "vim_dev"

[bug] access to uninitialized memory when drawing command line in silent mode

781) ==12739==by 0x669891: main (main.c:415) Vim is drawing the command line but I suppose that it should not try to draw it in silent mode (i.e. with -e -s command line options). Bug was found using afl-fuzz. Regards Dominique -- -- You received this message from the "vim_dev"

Re: Bug: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10

Hi mike, 2016/9/5 Mon 23:34:05 UTC+9 Michael Soyka wrote: > Hi Ken, > > On 9/5/2016 12:26 AM, Ken Takata wrote: > > Hi mike, > > > > 2016/9/5 Mon 10:07:00 UTC+9 Michael Soyka wrote: > >> The makefile testdir/Make_ming.mak contains statements of the form: > >> > >> if exist test.ok $(DEL)

[bug] read heap overflow in do_pending_operator()

Hi Here is one more bug found by afl-fuzz in vim-7.4.2330 an older: $ cat bug.vim new call append(0, [" a", "b"]) norm kVdggViw bw! %d $ valgrind --num-callers=20 vim -u NONE -S bug.vim -c q 2> log $ cat log ==7787== Memcheck, a memory error detector ==7787== Copyright

Re: [bug?][patch] Vim command completion is not performed, when expression register inserted

; > > > > > - Run vanilla vim with execute above file. > > > > $ vim -Nu NONE -S sample1.vim > > > > > > > > > > > > Expected behavior (I think): > > > > Current line displayed `autocomd BufAdd` and popup menu is appeared. >

Re: [bug?][patch] Vim command completion is not performed, when expression register inserted

gt; > > > > > > > > Expected behavior (I think): > > > Current line displayed `autocomd BufAdd` and popup menu is appeared. > > > > > > > > > Actual behavior: > > > completion is not performed. > > > Below message dipla

Re: Bug: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10

Hi Ken, On 9/5/2016 12:26 AM, Ken Takata wrote: Hi mike, 2016/9/5 Mon 10:07:00 UTC+9 Michael Soyka wrote: The makefile testdir/Make_ming.mak contains statements of the form: if exist test.ok $(DEL) test.ok which can only be executed by one of the DOS/Windows command shells such as

Re: Bug: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10

Hi mike, 2016/9/5 Mon 10:07:00 UTC+9 Michael Soyka wrote: > The makefile testdir/Make_ming.mak contains statements of the form: > >if exist test.ok $(DEL) test.ok > > which can only be executed by one of the DOS/Windows command shells such > as command.com or cmd.exe > > My version of

Bug: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10

The makefile testdir/Make_ming.mak contains statements of the form: if exist test.ok $(DEL) test.ok which can only be executed by one of the DOS/Windows command shells such as command.com or cmd.exe My version of make, gnu 3.82.90, sets the SHELL make variable to the value

Re: [bug][patch] invalid free() in channel_exe_cmd()

Ozaki Kiichi wrote: > There is a bug to try to release a variable on stack area. > > [repro steps] > > test.vim: > > let s:handle = ch_open('localhost:8765') > call ch_sendexpr(s:handle, 'hello!') > > > 1. run server "python runtime/tools/

Re: [bug] heap read overflow in vim-7.4.2323

61==by 0x46D991: do_cmdline_cmd (ex_docmd.c:715) > ==8161==by 0x5FA121: exe_commands (main.c:2896) > ==8161==by 0x5F7506: vim_main2 (main.c:781) > ==8161==by 0x5F6EB0: main (main.c:415) > > vim-7.4.52 that comes with xubuntu-14.04 does not have > the bug. "git bisect&q

[bug] heap read overflow in vim-7.4.2323

161==by 0x46D991: do_cmdline_cmd (ex_docmd.c:715) ==8161==by 0x5FA121: exe_commands (main.c:2896) ==8161==by 0x5F7506: vim_main2 (main.c:781) ==8161==by 0x5F6EB0: main (main.c:415) vim-7.4.52 that comes with xubuntu-14.04 does not have the bug. "git bisect" indicates that t

[bug][patch] invalid free() in channel_exe_cmd()

Hi. There is a bug to try to release a variable on stack area. [repro steps] test.vim: let s:handle = ch_open('localhost:8765') call ch_sendexpr(s:handle, 'hello!') 1. run server "python runtime/tools/demoserver.py" 2. vim -Nu NONE -S test.vim 3. input '["call&quo

Re: [bug?][patch] Vim command completion is not performed, when expression register inserted

; > > > > > Actual behavior: > > completion is not performed. > > Below message diplayed in last line. > > "-- Command-line completion (^V^N^P) Pattern not found" > > > > > > Is this bug? > > I don't know. But I wrote a patch

Re: [bug] use of free memory with 'formatexpr'

docmd.c:1110) > ==5251==by 0x46C017: do_source (ex_cmds2.c:4097) > ==5251==by 0x46B629: cmd_source (ex_cmds2.c:3710) > ==5251==by 0x46B57B: ex_source (ex_cmds2.c:3685) > ==5251==by 0x4718D4: do_one_cmd (ex_docmd.c:2962) > ==5251==by 0x46E355: do_cmdline (ex_docmd.c:1110)

Re: [bug] heap buffer overflow with CTRL-F and CTRL-B scrolling normal commands

Dominique Pellé wrote: > afl-fuzz found a heap buffer overflow in vim-7.4.2321 > and older. At least vim-7.4.52 in xubuntu-14.04 is > also affected so it's an old bug. > > Steps to reproduce: > > $ cat overflow.vim > norm oxx > exe "norm 2\" > exe

[bug] heap buffer overflow with CTRL-F and CTRL-B scrolling normal commands

Hi afl-fuzz found a heap buffer overflow in vim-7.4.2321 and older. At least vim-7.4.52 in xubuntu-14.04 is also affected so it's an old bug. Steps to reproduce: $ cat overflow.vim norm oxx exe "norm 2\" exe "norm 2\" $ valgrind vim -u NONE -S overflow.vim -c 'q!' 2>

[bug] use of free memory with 'formatexpr'

962) ==5251==by 0x46E355: do_cmdline (ex_docmd.c:1110) ==5251==by 0x46D991: do_cmdline_cmd (ex_docmd.c:715) ==5251==by 0x5FA0F2: exe_commands (main.c:2896) ==5251==by 0x5F74D7: vim_main2 (main.c:781) ==5251==by 0x5F6E81: main (main.c:415) (...snip many other errors...) It's an old

Re: [bug] vim-7.4.2311 crashes with deleted augroup, regression introduced by vim-7.4.2117

Dominique wrote: > afl-fuzz found another crash in Vim-7.4.2311 and older: > > $ cat crash.vim > augroup x > augroup! x > au VimEnter * echo > au VimEnter > > $ vim -u NONE -S crash.vim > Vim: Caught deadly signal SEGV > Vim: Finished. > Segmentation fault (core dumped) > > program received

Re: [bug?][patch] Vim command completion is not performed, when expression register inserted

le. > $ vim -Nu NONE -S sample1.vim > > > Expected behavior (I think): > Current line displayed `autocomd BufAdd` and popup menu is appeared. > > > Actual behavior: > completion is not performed. > Below message diplayed in last line. > "-- Command-line completion (

Re: [bug] vim-7.4.2305 crashes in bugIsChanged with NULL buf pointer

Dominique Pellé wrote: > I see that patch 7.4.2309 fixed it. Thanks. > > However, I see another case found by afl-fuzz > that still crashes in Vim-7.4.2311 with a > similar stack: > > $ cat crash2.vim > tabedit > autocmd BufUnload tabnext > f x > e y Thanks. It's hard to think of all corner

Re: [bug] vim-7.4.2305 crashes in bugIsChanged with NULL buf pointer

06410b7 in vim_main2 () at main.c:877 >> #5 0x0000006407ed in main (argc=5, argv=0x7fffd7d8) at main.c:415 >> >> (gdb) p buf >> $1 = (buf_T *) 0x0 >> >> It's a regression since vim-7.4.712 that comes with Ubuntu-15.10 >> does not crash. git b

[bug] vim-7.4.2311 crashes with deleted augroup, regression introduced by vim-7.4.2117

Hi afl-fuzz found another crash in Vim-7.4.2311 and older: $ cat crash.vim augroup x augroup! x au VimEnter * echo au VimEnter $ vim -u NONE -S crash.vim Vim: Caught deadly signal SEGV Vim: Finished. Segmentation fault (core dumped) program received signal SIGSEGV, Segmentation fault.

[bug?][patch] Vim command completion is not performed, when expression register inserted

): Current line displayed `autocomd BufAdd` and popup menu is appeared. Actual behavior: completion is not performed. Below message diplayed in last line. "-- Command-line completion (^V^N^P) Pattern not found" Is this bug? I don't know. But I wrote a patch with a test. Please che

Re: [patch] fixed use of free memory with timers (bug introduced in Vim-7.4.2304)

Dominique Pellé wrote: > Valgrind detects use of free memory in Vim-7.4.2305 > Bug was introduced in Vim-7.4.2304. > > $ valgrind 2> log vim -u NONE -c 'call timer_start(0, "x")' > > ==11797== Memcheck, a memory error detector > ==11797== Copyright (C) 2

Re: [bug] vim-7.4.2305 crashes in bugIsChanged with NULL buf pointer

1 = (buf_T *) 0x0 > > It's a regression since vim-7.4.712 that comes with Ubuntu-15.10 > does not crash. git bisect found that the bug was introduced in: > > == > e59215c7dcae17b03daf39517560cfaa03314f5a is the first bad commit > commit e59215c7dcae17b03daf39517560cfaa03314f5a &g

[bug] vim-7.4.2305 crashes in bugIsChanged with NULL buf pointer

main.c:877 #5 0x006407ed in main (argc=5, argv=0x7fffd7d8) at main.c:415 (gdb) p buf $1 = (buf_T *) 0x0 It's a regression since vim-7.4.712 that comes with Ubuntu-15.10 does not crash. git bisect found that the bug was introduced in: == e59215c7dcae17b03daf39517560cfaa03314f5a is the fi

Re: [bug] g< does not work with execute()/redir

Christian Brabandt wrote: > > > There is a bug when using g< with execute() > > > > > > One cannot capture it's output using execute()/redir: > > > > > > :echo "a\nb\nc\nd\n" > > > (press enter prompt) > > > :norm! g&

Re: [bug] g< does not work with execute()/redir

On Do, 01 Sep 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > There is a bug when using g< with execute() > > > > One cannot capture it's output using execute()/redir: > > > > :echo "a\nb\nc\nd\n" > > (press en

[patch] fixed use of free memory with timers (bug introduced in Vim-7.4.2304)

Hi Valgrind detects use of free memory in Vim-7.4.2305 Bug was introduced in Vim-7.4.2304. $ valgrind 2> log vim -u NONE -c 'call timer_start(0, "x")' ==11797== Memcheck, a memory error detector ==11797== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==11797== U

Re: [bug] g< does not work with execute()/redir

Hi Bram! On Do, 01 Sep 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > There is a bug when using g< with execute() > > > > One cannot capture it's output using execute()/redir: > > > > :echo "a\nb\nc\nd\n" > > (pr

Re: [bug] g< does not work with execute()/redir

Christian Brabandt wrote: > There is a bug when using g< with execute() > > One cannot capture it's output using execute()/redir: > > :echo "a\nb\nc\nd\n" > (press enter prompt) > :norm! g< > (shows the echo output again) > :let b=execute(':unsilent

Re: YML formatting inconsistent bug

Am 2016-09-01 04:16, schrieb Kai Hendry: As reported here: https://bugs.archlinux.org/task/50557 Description: When formatting a YML file, it's left inconsistent. http://s.natalian.org/2016-08-29/vim-yml.mp4 https://github.com/kaihendry/count/blob/master/.travis.yml filetype detection:ON

YML formatting inconsistent bug

As reported here: https://bugs.archlinux.org/task/50557 Description: When formatting a YML file, it's left inconsistent. http://s.natalian.org/2016-08-29/vim-yml.mp4 https://github.com/kaihendry/count/blob/master/.travis.yml filetype detection:ON plugin:ON indent:ON filetype=yaml Additional

[bug] g< does not work with execute()/redir

There is a bug when using g< with execute() One cannot capture it's output using execute()/redir: :echo "a\nb\nc\nd\n" (press enter prompt) :norm! g< (shows the echo output again) :let b=execute(':unsilent norm! g<') :echo empty(b) 1 :norm! g< (does not output anything) B

bug with :changes?

Bram, I see the following behaviour: fun! Test() new call setline(1, range(1,100)) call append('$', ['a', 'b', 'c', 'd']) call append('$', ['Z', 'Y', 'X', 'W']) endfu call vim like this: vim -u NONE -N -S testfile.vim Now check the :changes command: :changes This will show: , |

Re: bug with folding

ble > norm! Vzc -> correctly folds 3-4 > :set nofoldenable > norm! zc -> folds lines 3-4? Actually, I can't seem to verify this bug on a recent Vim. It seems to always fold the longer range. Can someone confirm this behaviour? Best, Christian -- -- You received this message from th

Re: bug with folding

r several lines below where it definitly shouldn't. > > Unfortunately, I can't reproduce this problem anymore. > > The rules for opening a closing folds are a bit complicated... > It's possible there is a bug, but it's also possible that something is > missing in the documenta

Re: bug with folding

3-4? Isn't this because 'foldlevel' keeps the same value when 'foldenable' is reset? > Also I got another session, where zF create one additional closing > fold marker several lines below where it definitly shouldn't. > Unfortunately, I can't reproduce this problem anymore. The rules for openi

bug with folding

Bram, I am currently writing some tests for normal.c, to increase the coverage. Unfortunately, I noteiced some bugs with folding: Here is one issue: ~$ vim -u NONE -N call setline(1, range(1,10) :3 norm! 2zF :2 norm! 5zF :set nofoldenable :3 norm! zc -> folds line 2 - 8, I would have expected

Re: [bug] memory leak with getbufinfo() and signs in Vim-7.4.2275

Yegappan Lakshmanan wrote: > On Sun, Aug 28, 2016 at 1:56 AM, Dominique Pell=C3=A9 > wrote: > > Hi > > > > I see a memory leak in Vim-7.4.2275 which can be > > reproduced by: > > > > $ valgrind --leak-check=3Dyes --num-callers=3D50 \ > >vim -u NONE -N \ > >-c

Re: [bug] memory leak with getbufinfo() and signs in Vim-7.4.2275

Dominique Pellé wrote: > I see a memory leak in Vim-7.4.2275 which can be > reproduced by: > > $ valgrind --leak-check=yes --num-callers=50 \ >vim -u NONE -N \ >-c 'sign define Sign text=x' \ >-c 'exe "sign place 1 line=3 name=Sign buffer=" . bufnr("%")' \ >-c 'echo

Re: [bug] memory leak with getbufinfo() and signs in Vim-7.4.2275

Hi Dominique, On Sun, Aug 28, 2016 at 1:56 AM, Dominique Pellé wrote: > Hi > > I see a memory leak in Vim-7.4.2275 which can be > reproduced by: > > $ valgrind --leak-check=yes --num-callers=50 \ >vim -u NONE -N \ >-c 'sign define Sign text=x' \ >-c 'exe

[bug] memory leak with getbufinfo() and signs in Vim-7.4.2275

Hi I see a memory leak in Vim-7.4.2275 which can be reproduced by: $ valgrind --leak-check=yes --num-callers=50 \ vim -u NONE -N \ -c 'sign define Sign text=x' \ -c 'exe "sign place 1 line=3 name=Sign buffer=" . bufnr("%")' \ -c 'echo getbufinfo()' \ -c q 2> log And log file

Re: Bug in creating a new quickfix list using setqflist()

Yegappan wrote: > If the setqflist() function is used to create an empty quickfix list > with a title and then entries are added to the list, then the title > gets reset. Also, it is not possible to create a new empty quickfix > list with the setqflist() function with a specific title. The

Bug in creating a new quickfix list using setqflist()

Hi all, If the setqflist() function is used to create an empty quickfix list with a title and then entries are added to the list, then the title gets reset. Also, it is not possible to create a new empty quickfix list with the setqflist() function with a specific title. The attached patch fixes

Re: [bug][patch] Unexpectedly preview window opened, after the `:ptjump` command canceled.

Hirohito Higashi wrote: > Hi Bram and developers, > > How to reproduce: > - Change directory to your local vim/src directory. > $ cd /path-to-your-vim-clone-dir/vim/src > - Start vanilla Vim. > $ ./vim -Nu NONE > - Do tagjump and display in the preview window. (In fact, it becomes selected

[bug][patch] Unexpectedly preview window opened, after the `:ptjump` command canceled.

Hi Bram and developers, How to reproduce: - Change directory to your local vim/src directory. $ cd /path-to-your-vim-clone-dir/vim/src - Start vanilla Vim. $ ./vim -Nu NONE - Do tagjump and display in the preview window. (In fact, it becomes selected wait because candidates are two)

(bug) :sil!, :try and :echoerr

quot; worse: this command confuses Vim :sil! throw 'foo' " nothing (bug) -- Andy -- -- 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 --

Re: [bug] crash with funcref in vim-7.4.2232

Dominique wrote: > afl-fuzz found this command which crashes vim-7.4.2232: > > $ vim -u NONE -c "echo funcref('{')" > Vim: Caught deadly signal SEGV > Vim: Finished. > Segmentation fault (core dumped) > > In gdb: > > Program received signal SIGSEGV, Segmentation fault. >

[bug] crash with funcref in vim-7.4.2232

Hi afl-fuzz found this command which crashes vim-7.4.2232: $ vim -u NONE -c "echo funcref('{')" Vim: Caught deadly signal SEGV Vim: Finished. Segmentation fault (core dumped) In gdb: Program received signal SIGSEGV, Segmentation fault. 0x004c1e26 in hash_hash (key=0x0) at

Re: [bug] write beyond end of string when calling feedkeys

Dominique wrote: > Valgrind shows a write beyond end of string > in Vim-7.4. (huge) and older when doing: > > $ vim -u NONE -N -S bug-feedkeys-7.4.7222.vim 2> log > > ... where bug-feedkeys-7.4.7222.vim is the one-line > attached file. Note that the file is in

[bug] write beyond end of string when calling feedkeys

Hi Valgrind shows a write beyond end of string in Vim-7.4. (huge) and older when doing: $ vim -u NONE -N -S bug-feedkeys-7.4.7222.vim 2> log ... where bug-feedkeys-7.4.7222.vim is the one-line attached file. Note that the file is in latin1 encoding and my locale is en_US.UTF-8. log f

Re: Bug in complete() function?

> It mentions version 7.4.0, that's very old. Many completion bugs have > already been fixed. > > It would be nicer if you can copy the essential information here, so > that not everybody has to navigate to some website to see the contents. Thanks for the reply. I tried it on 7.4.2196 and it

Re: Bug in complete() function?

Tumbler Terrall wrote: > If the complete() function is used and the user backspaces, vim goes into > "Whole line completion" mode. I'm curious if this is intended or if it is a > bug. > > It kind of seems like a bug to me since if you press CTRL-e the wh

Bug in complete() function?

If the complete() function is used and the user backspaces, vim goes into "Whole line completion" mode. I'm curious if this is intended or if it is a bug. It kind of seems like a bug to me since if you press CTRL-e the whole line gets replaced by the current word in certain circumstan

Re: Match conceal bug

Rom Grk wrote: > 1. Open any file, with vim/nvim -u NONE > 2. :set cole=1 hls > 3. :match Conceal /word/ => 'word' concealed > 4. /another_word => 'another_word' concealed > > Tested with vim 7.4.2143 Resetting 'hls' makes it work again. Looks like the match and highlighting are mixed up. --

Match conceal bug

1. Open any file, with vim/nvim -u NONE 2. :set cole=1 hls 3. :match Conceal /word/ => 'word' concealed 4. /another_word => 'another_word' concealed Tested with vim 7.4.2143 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are

<    1   2   3   4   5   6   7   8   9   10   >