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

[Dominique Pellé]

Bram Moolenaar wrote:

> Dominique Pellé wrote:
>
>> The attached script causes vim-7.4.2305 to crash:
>>
>> $ cat crash.vim
>> new
>> tabedit
>> tabfirst
>> au BufUnload  tabnext
>> q
>>
>> $ vim -u NONE -S crash.vim
>> Vim: Caught deadly signal SEGV
>> Vim: Finished.
>> Segmentation fault (core dumped)
>>
>> 3518│ int
>> 3519│ bufIsChanged(buf_T *buf)
>> 3520│ {
>> 3521│ return
>> 3522│ #ifdef FEAT_QUICKFIX
>> 3523│ !bt_dontwrite(buf) &&
>> 3524│ #endif
>> 3525├>(buf->b_changed || file_ff_differs(buf, TRUE));
>> 3526│ }
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x005eee37 in bufIsChanged (buf=0x0) at undo.c:3525
>> (gdb) bt
>> #0  0x005eee37 in bufIsChanged (buf=0x0) at undo.c:3525
>> #1  0x0058cd9b in draw_tabline () at screen.c:10407
>> #2  0x00579548 in update_screen (type=40) at screen.c:638
>> #3  0x006416dd in main_loop (cmdwin=0, noexmode=0) at main.c:1211
>> #4  0x006410b7 in vim_main2 () at 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 first bad commit
>> commit e59215c7dcae17b03daf39517560cfaa03314f5a
>> Author: Bram Moolenaar 
>> Date:   Sun Aug 14 19:08:45 2016 +0200
>>
>> patch 7.4.2212
>> Problem:Mark " is not set when closing a window in another tab. 
>> (Guraga)
>> Solution:   Check all tabs for the window to be valid. (based on patch by
>> Hirohito Higashi, closes #974)
>> ==
>>
>> Crash was found by fuzzing with American fuzzy lop.
>
> Easy to reproduce, thanks.


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

$ valgrind vim -u NONE -S crash2.vim

valgrind ./vim -u NONE -S crash2.vim 2> log
==7359== Memcheck, a memory error detector
==7359== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7359== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==7359== Command: vim -u NONE -S crash2.vim
==7359==
==7359== Invalid read of size 4
==7359==at 0x5E3D53: bufIsChanged (undo.c:3525)
==7359==by 0x582ECD: draw_tabline (screen.c:10407)
==7359==by 0x56F8A0: update_screen (screen.c:638)
==7359==by 0x624247: main_loop (main.c:1211)
==7359==by 0x623C45: vim_main2 (main.c:877)
==7359==by 0x62338A: main (main.c:415)
==7359==  Address 0xc8 is not stack'd, malloc'd or (recently) free'd
==7359==
==7359==
==7359== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==7359==at 0x7E27F07: kill (syscall-template.S:81)
==7359==by 0x5376C1: may_core_dump (os_unix.c:3346)
==7359==by 0x537660: mch_exit (os_unix.c:3312)
==7359==by 0x6247F8: getout (main.c:1495)
==7359==by 0x4EF04D: preserve_exit (misc1.c:9494)
==7359==by 0x535485: deathtrap (os_unix.c:1164)
==7359==by 0x7E27CAF: ??? (in /lib/x86_64-linux-gnu/libc-2.19.so)
==7359==by 0x5E3D52: bufIsChanged (undo.c:3525)
==7359==by 0x582ECD: draw_tabline (screen.c:10407)
==7359==by 0x56F8A0: update_screen (screen.c:638)
==7359==by 0x624247: main_loop (main.c:1211)
==7359==by 0x623C45: vim_main2 (main.c:877)

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.

[patch] corrections in runtime/doc/version8.txt

[Dominique Pellé]

Hi

Attached patch has corrections in runtime/doc/version8.txt.

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.
diff --git a/runtime/doc/version8.txt b/runtime/doc/version8.txt
index 61299fb..b7f7b3e 100644
--- a/runtime/doc/version8.txt
+++ b/runtime/doc/version8.txt
@@ -6364,7 +6364,7 @@ Files:  src/testdir/Make_dos.mak
 
 Patch 7.4.995
 Problem:gdk_pixbuf_new_from_inline() is deprecated.
-Solution:   Generate auto/gui_gtk_gresources.c. (Kazunobu Kazunobu,
+Solution:   Generate auto/gui_gtk_gresources.c. (Kazunobu Kuriyama),
 closes #507)
 Files:  src/Makefile, src/auto/configure, src/config.h.in,
 src/config.mk.in, src/configure.in, src/gui_gtk.c,
@@ -7848,7 +7848,7 @@ Files:  src/os_win32.c
 Patch 7.4.1231
 Problem:JSON messages are not parsed properly.
 Solution:   Queue received messages.
-Files:  src/eval,c src/channel.c, src/json.c, src/proto/eval.pro,
+Files:  src/eval.c src/channel.c, src/json.c, src/proto/eval.pro,
 src/proto/channel.pro, src/proto/json.pro, src/structs.h
 
 Patch 7.4.1232
@@ -9312,7 +9312,7 @@ Problem:":loadplugin" is not optimal, some people find it confusing.
 Solution:   Only use ":packadd" with an optional "!".
 Files:  src/ex_cmds.h, src/ex_cmds2.c, src/testdir/test_loadplugin.vim,
 src/testdir/test_packadd.vim, src/testdir/Make_all.mak,
-runtime/doc/repeat.txt.
+runtime/doc/repeat.txt
 
 Patch 7.4.1487
 Problem:For WIN32 isinf() is defined as a macro.
@@ -10164,7 +10164,7 @@ Files:  src/ops.c, src/testdir/test_increment.vim
 Patch 7.4.1635
 Problem:Channel test is a bit flaky.
 Solution:   Remove 'DETACH' if it's there.
-Files:  src/test_channel.vim
+Files:  src/testdir/test_channel.vim
 
 Patch 7.4.1636
 Problem:When 'F' is in 'shortmess' the prompt for the encryption key isn't
@@ -10824,7 +10824,7 @@ Files:  src/normal.c, src/testdir/test_goto.vim, src/testdir/test_alot.vim
 Patch 7.4.1749
 Problem:When using GTK 3.20 there are a few warnings.
 Solution:   Use new functions when available. (Kazunobu Kuriyama)
-Files:  src/gui_beval,c src/gui_gtk_x11.c
+Files:  src/gui_beval.c src/gui_gtk_x11.c
 
 Patch 7.4.1750
 Problem:When a buffer gets updated while in command line mode, the screen
@@ -13605,7 +13605,7 @@ Files:  src/getchar.c, src/proto/getchar.pro, src/misc1.c,
 Patch 7.4.2223
 Problem:Buffer overflow when using latin1 character with feedkeys().
 Solution:   Check for an illegal character.  Add a test.
-Files:  src/testdir/test_regexp_utf8.vim, src/testdir/test_source.vim,
+Files:  src/testdir/test_regexp_utf8.vim, src/testdir/test_source_utf8.vim,
 src/testdir/test_alot_utf8.vim, src/Makefile, src/getchar.c,
 src/macros.h, src/evalfunc.c, src/os_unix.c, src/os_win32.c,
 src/spell.c,

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

[Dominique Pellé]

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.
0x0062cc86 in msg_puts_display (str=0x0, maxlen=-1, attr=0,
recurse=0) at message.c:1937
(gdb) bt
#0  0x0062cc86 in msg_puts_display (str=0x0, maxlen=-1,
attr=0, recurse=0) at message.c:1937
#1  0x0062c5a3 in msg_puts_attr_len (str=0x0, maxlen=-1,
attr=0) at message.c:1910
#2  0x0062c4e7 in msg_puts_attr (s=0x0, attr=0) at message.c:1861
#3  0x004ab567 in show_autocmd (ap=0x932700,
event=EVENT_VIMENTER) at fileio.c:7816
#4  0x004ac7a5 in do_autocmd_event (event=EVENT_VIMENTER,
pat=0x931f8b "", nested=0, cmd=0x931f8b "", forceit=0
, group=-3) at fileio.c:8529
#5  0x004ac570 in do_autocmd (arg_in=0x931f83 "VimEnter",
forceit=0) at fileio.c:8440
#6  0x00480ca1 in ex_autocmd (eap=0x7fffcae0) at ex_docmd.c:5488
#7  0x0047bdc7 in do_one_cmd (cmdlinep=0x7fffccf0,
sourcing=1, cstack=0x7fffcde0, fgetline=0x4769a3 , cookie=0x7fffd340) at ex_docmd.c:2967
#8  0x00478823 in do_cmdline (cmdline=0x931e70 "augroup x",
fgetline=0x4769a3 , cookie=0x7ff
fd340, flags=7) at ex_docmd.c:1110
#9  0x0047659d in do_source (fname=0x931c13 "c.vim",
check_other=0, is_vimrc=0) at ex_cmds2.c:4097
#10 0x00475baf in cmd_source (fname=0x931c13 "c.vim",
eap=0x7fffd550) at ex_cmds2.c:3710
#11 0x00475afd in ex_source (eap=0x7fffd550) at ex_cmds2.c:3685
#12 0x0047bdc7 in do_one_cmd (cmdlinep=0x7fffd760,
sourcing=1, cstack=0x7fffd850, fgetline=0x0, cookie=
0x0) at ex_docmd.c:2967
#13 0x00478823 in do_cmdline (cmdline=0x8eb7e0 "so c.vim",
fgetline=0x0, cookie=0x0, flags=11) at ex_docmd.c:11
10
#14 0x00477e5f in do_cmdline_cmd (cmd=0x8eb7e0 "so c.vim") at
ex_docmd.c:715
#15 0x00625ac1 in exe_commands (parmp=0x8ce200 ) at main.c:2896
#16 0x00622bee in vim_main2 () at main.c:781
#17 0x006224ef in main (argc=6, argv=0x7fffdea8) at main.c:415

1917│ static void
1918│ msg_puts_display(
1919│ char_u  *str,
1920│ int maxlen,
1921│ int attr,
1922│ int recurse)
1923│ {
1924│ char_u  *s = str;
1925│ char_u  *t_s = str; /* string from "t_s" to "s" is
still todo */
1926│ int t_col = 0;  /* screen cells todo, 0 when
"t_s" not used */
1927│ #ifdef FEAT_MBYTE
1928│ int l;
1929│ int cw;
1930│ #endif
1931│ char_u  *sb_str = str;
1932│ int sb_col = msg_col;
1933│ int wrap;
1934│ int did_last_char;
1935│
1936│ did_wait_return = FALSE;
1937├>while ((maxlen < 0 || (int)(s - str) < maxlen) && *s != NUL)
1938│ {

(gdb) p s
$1 = (char_u *) 0x0

#1  0x0064ac7f in msg_puts_attr_len (str=0x0, maxlen=-1,
attr=0) at message.c:1910
(gdb) up
#2  0x0064abc3 in msg_puts_attr (s=0x0, attr=0) at message.c:1861
(gdb) up
#3  0x004b145d in show_autocmd (ap=0x959780,
event=EVENT_VIMENTER) at fileio.c:7816

7815│ if (AUGROUP_NAME(ap->group) == NULL)
7816├>msg_puts_attr(deleted_augroup, hl_attr(HLF_E));
7817│ else
7818│ msg_puts_attr(AUGROUP_NAME(ap->group), hl_attr(HLF_T));

(gdb) p deleted_augroup
$2 = (char_u *) 0x0

It does not crash using vim-7.4.752 that comes with xubuntu-15.10
so it's a regression.

git bisect identified that it started to crash in Vim-7.4.2117:

===
f2c4c391192cab6e923b1a418d4af09106fba25f is the first bad commit
commit f2c4c391192cab6e923b1a418d4af09106fba25f
Author: Bram Moolenaar 
Date:   Fri Jul 29 20:50:24 2016 +0200

patch 7.4.2117
Problem:Deleting an augroup that still has autocmds does not give a
warning.  The next defined augroup takes its place.
Solution:   Give a warning and prevent the index being used for
another group
name.
===

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.

Re: [vim/vim] defaults.vim overwrites /etc/vimrc (#1033)

[David Fishburn]

On Fri, Sep 2, 2016 at 4:24 PM, Christian Hesse 
wrote:

> Since version 7.4.2111 we load a less conservative defaults.vim file if
> ~/.vimrc is not found. These options can not be overwritten from global
> /etc/vimrc.
> For example the new defaults enable mouse integration. To disable mouse
> integration I have to create ~/.vimrc for every user. I can *not* disable
> mouse integration from /etc/vimrc.
>
> IMHO /etc/vimrc should have precedence to the default settings.
>
>
I second this on my *nix systems, I only create a vimrc (no .vimrc) so that
I get the same settings for each and every user on the machine.

David

-- 
-- 
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?][patch] Vim command completion is not performed, when expression register inserted

[h_east]

Hi Bram and list,

How to reproduce:
- Prepare the following vim script file.
  $ cat sample1.vim
function! Sample()
return 'autocmd '
endfunction
call feedkeys("i\=Sample()\\\")

- 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.


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 check an attached patch.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)

-- 
-- 
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.
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 110a95a..7d58ed1 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -4512,6 +4512,8 @@ set_cmd_context(
 	/* pass CMD_SIZE because there is no real command */
 	set_context_for_expression(xp, str, CMD_SIZE);
 # endif
+	while (nextcomm != NULL)
+	nextcomm = set_one_cmd_context(xp, nextcomm);
 }
 else if (ccline.input_fn)
 {
diff --git a/src/testdir/test_autocmd.vim b/src/testdir/test_autocmd.vim
index 6db3bf7..767753f 100644
--- a/src/testdir/test_autocmd.vim
+++ b/src/testdir/test_autocmd.vim
@@ -172,6 +172,7 @@ func Test_augroup_warning()
   augroup Another
   augroup END
   call assert_true(match(execute('au VimEnter'), "-Deleted-.*VimEnter") >= 0)
+  augroup! Another
 
   " no warning for postpone aucmd delete
   augroup StartOK
diff --git a/src/testdir/test_popup.vim b/src/testdir/test_popup.vim
index 34a2251..cd87e00 100644
--- a/src/testdir/test_popup.vim
+++ b/src/testdir/test_popup.vim
@@ -236,22 +236,27 @@ func! Test_popup_completion_insertmode()
   iunmap 
 endfunc
 
-function! ComplTest() abort
-  call complete(1, ['source', 'soundfold'])
-  return ''
-endfunction
-
 func Test_noinsert_complete()
+  function! s:complTest1() abort
+call complete(1, ['source', 'soundfold'])
+return ''
+  endfunction
+
+  function! s:complTest2() abort
+call complete(1, ['source', 'soundfold'])
+return ''
+  endfunction
+
   new
   set completeopt+=noinsert
-  inoremap   =ComplTest()
+  inoremap   =s:complTest1()
   call feedkeys("i\soun\\\.", 'tx')
   call assert_equal('soundfold', getline(1))
   call assert_equal('soundfold', getline(2))
   bwipe!
 
   new
-  inoremap   =Test()
+  inoremap   =s:complTest2()
   call feedkeys("i\\\", 'tx')
   call assert_equal('source', getline(1))
   bwipe!
@@ -260,10 +265,17 @@ func Test_noinsert_complete()
   iunmap 
 endfunc
 
+func Test_compl_vim_cmds_after_register_expr()
+  function! s:test_func()
+return 'autocmd '
+  endfunction
 
-function! Test() abort
-  call complete(1, ['source', 'soundfold'])
-  return ''
-endfunction
+  new
+  call feedkeys("i\=s:test_func()", 'tx')
+  " When a new autocmd event is added before the 'BufAdd' in ascending order,
+  " we will be a need to change here.
+  call assert_equal('autocmd BufAdd', getline(1))
+  bwipe!
+endfunc
 
 " vim: shiftwidth=2 sts=2 expandtab

Re: Patch 7.4.2299

[LCD 47]

On 2 September 2016, Bram Moolenaar  wrote:
>
> Lcd wrote:
>
> > On 1 September 2016, Bram Moolenaar  wrote:
> > >
> > > Patch 7.4.2299 Problem:  QuickFixCmdPre and QuickFixCmdPost
> > > autocommands are not always triggered.  Solution:  Also trigger
> > > on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files:
> > > src/quickfix.c, src/testdir/test_quickfix.vim
> > [...]
> >
> > Sadly, this breaks the interaction of "syntastic" with all
> > plugins that hook to QuickFixCmdPre or QuickFixCmdPost.  An example
> > of such plugin is "ferret".  These plugins now have to be fixed to
> > be aware that they may be called from things like :lgetexpr.  I'd
> > argue that running QuickFixCmd* for :lgetexpr makes little sense,
> > since :lgetexpr is almost never called run interactively.  So, was
> > there an actual reason for this change, right before the release of
> > Vim 8?
>
> Can you give more details about what breaks?  The autocommands are
> there to allow plugins to deal with changes in the Quickfix list.  I
> hope it's not actually being used for something else.

As I said in another message, people do thinge like this:

if has('autocmd')
augroup Ferret
autocmd!
autocmd QuickFixCmdPost [^l]* nested cwindow
autocmd QuickFixCmdPost l* nested lwindow
augroup END
endif

This is fine for opening grep windows automatically and what not,
but the loclists created by things like lgetexpr are typically parsing
in progress, and are never meant to be displayed at that stage.  Plugins
calling lgetexpr are now all of a sudden calling autocmds from unrelated
plugins.

As Christian Brabandt points out, this can be prevented by doing
something like "noautocmd lgetexpr ...", and thus fixing something that
was never broken.  Or it can be prevented by adding a more restrictive
pattern in autocmd QuickFixCmd, and thus avoiding a pitfall that
didn't exist before 7.4.2299. _shrug_

/lcd

-- 
-- 
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: Patch 7.4.2299

[LCD 47]

On 2 September 2016, Christian Brabandt  wrote:
> Hi LCD!
>
> On Fr, 02 Sep 2016, LCD 47 wrote:
>
> > On 2 September 2016, Ingo Karkat  wrote:
> > > On 09/02/2016 09:51 PM, LCD 47 wrote:
> > > > On 1 September 2016, Bram Moolenaar  wrote:
> > > >>
> > > >> Patch 7.4.2299 Problem:  QuickFixCmdPre and QuickFixCmdPost
> > > >> autocommands are not always triggered.  Solution:  Also trigger
> > > >> on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files:
> > > >> src/quickfix.c, src/testdir/test_quickfix.vim
> > > > [...]
> > > >
> > > > Sadly, this breaks the interaction of "syntastic" with all
> > > > plugins that hook to QuickFixCmdPre or QuickFixCmdPost.  An
> > > > example of such plugin is "ferret".  These plugins now have to
> > > > be fixed to be aware that they may be called from things like
> > > > :lgetexpr.  I'd argue that running QuickFixCmd* for :lgetexpr
> > > > makes little sense, since :lgetexpr is almost never called run
> > > > interactively.  So, was there an actual reason for this change,
> > > > right before the release of Vim 8?
> > >
> > > I use the QuickFixCmdPre/Post to automatically open / adapt the
> > > size of / close the quickfix window, and therefore appreciate that
> > > all quickfix-manipulating commands are covered.
> > >
> > > The fix of Syntastic should be pretty easy, as one can use the
> > > autocmd pattern to exclude [cl]getexpr, right?
> >
> > Syntastic is at the receiving end of this game, it just runs
> > :lgetexpr.  All of a sudden :lgetexpr now triggers autocmds in other
> > plugins, and there isn't anything syntastic can do about that.  Said
> > plugins need to become aware of the new scope of their harmless
> > little autocmds, become aware that they are now called from
> > other plugins' code, and fix the calls, as you say, to exclude
> > [cl]getexpr.  I'm sure they are all going to be fixed in no time. :)
>
> Hm, can't you call noa lgetexpr ... ?

Hmm, I wasn't aware of :noautocmd.  Thank you so much, this does
provide a workaround for syntastic.

/lcd

-- 
-- 
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: Patch 7.4.2299

[Bram Moolenaar]

Lcd wrote:

> On 1 September 2016, Bram Moolenaar  wrote:
> > 
> > Patch 7.4.2299
> > Problem:QuickFixCmdPre and QuickFixCmdPost autocommands are not always
> > triggered.
> > Solution:   Also trigger on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan)
> > Files:  src/quickfix.c, src/testdir/test_quickfix.vim
> [...]
> 
> Sadly, this breaks the interaction of "syntastic" with all plugins
> that hook to QuickFixCmdPre or QuickFixCmdPost.  An example of such
> plugin is "ferret".  These plugins now have to be fixed to be aware that
> they may be called from things like :lgetexpr.  I'd argue that running
> QuickFixCmd* for :lgetexpr makes little sense, since :lgetexpr is almost
> never called run interactively.  So, was there an actual reason for this
> change, right before the release of Vim 8?

Can you give more details about what breaks?  The autocommands are there
to allow plugins to deal with changes in the Quickfix list.  I hope it's
not actually being used for something else.

-- 
hundred-and-one symptoms of being an internet addict:
143. You dream in pallettes of 216 websafe colors.

 /// 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: Patch 7.4.2299

[LCD 47]

On 2 September 2016, LCD 47  wrote:
> On 2 September 2016, Ingo Karkat  wrote:
> > On 09/02/2016 09:51 PM, LCD 47 wrote:
> > > On 1 September 2016, Bram Moolenaar  wrote:
> > >>
> > >> Patch 7.4.2299 Problem:  QuickFixCmdPre and QuickFixCmdPost
> > >> autocommands are not always triggered.  Solution:  Also trigger
> > >> on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files:
> > >> src/quickfix.c, src/testdir/test_quickfix.vim
> > > [...]
> > >
> > > Sadly, this breaks the interaction of "syntastic" with all
> > > plugins that hook to QuickFixCmdPre or QuickFixCmdPost.  An
> > > example of such plugin is "ferret".  These plugins now have to
> > > be fixed to be aware that they may be called from things like
> > > :lgetexpr.  I'd argue that running QuickFixCmd* for :lgetexpr
> > > makes little sense, since :lgetexpr is almost never called run
> > > interactively.  So, was there an actual reason for this change,
> > > right before the release of Vim 8?
> >
> > I use the QuickFixCmdPre/Post to automatically open / adapt the size
> > of / close the quickfix window, and therefore appreciate that all
> > quickfix-manipulating commands are covered.
> >
> > The fix of Syntastic should be pretty easy, as one can use the
> > autocmd pattern to exclude [cl]getexpr, right?
>
> Syntastic is at the receiving end of this game, it just runs
> :lgetexpr.  All of a sudden :lgetexpr now triggers autocmds in other
> plugins, and there isn't anything syntastic can do about that.  Said
> plugins need to become aware of the new scope of their harmless little
> autocmds, become aware that they are now called from other plugins'
> code, and fix the calls, as you say, to exclude [cl]getexpr.  I'm sure
> they are all going to be fixed in no time. :)

An example: ferret does this:

if has('autocmd')
augroup Ferret
autocmd!
autocmd QuickFixCmdPost [^l]* nested cwindow
autocmd QuickFixCmdPost l* nested lwindow
augroup END
endif

There are people recommending this setting on StackOverflow and
friends, presumably because the point of quicklfix lists is to be
opened, so this is probably a pretty popular setting by now.  In the
mean time, "syntastic no longer works under Vim 8".

/lcd

-- 
-- 
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: Patch 7.4.2299

[Christian Brabandt]

Hi LCD!

On Fr, 02 Sep 2016, LCD 47 wrote:

> On 2 September 2016, Ingo Karkat  wrote:
> > On 09/02/2016 09:51 PM, LCD 47 wrote:
> > > On 1 September 2016, Bram Moolenaar  wrote:
> > >>
> > >> Patch 7.4.2299 Problem:  QuickFixCmdPre and QuickFixCmdPost
> > >> autocommands are not always triggered.  Solution:  Also trigger
> > >> on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files:
> > >> src/quickfix.c, src/testdir/test_quickfix.vim
> > > [...]
> > >
> > > Sadly, this breaks the interaction of "syntastic" with all
> > > plugins that hook to QuickFixCmdPre or QuickFixCmdPost.  An example
> > > of such plugin is "ferret".  These plugins now have to be fixed to
> > > be aware that they may be called from things like :lgetexpr.  I'd
> > > argue that running QuickFixCmd* for :lgetexpr makes little sense,
> > > since :lgetexpr is almost never called run interactively.  So, was
> > > there an actual reason for this change, right before the release of
> > > Vim 8?
> >
> > I use the QuickFixCmdPre/Post to automatically open / adapt the size
> > of / close the quickfix window, and therefore appreciate that all
> > quickfix-manipulating commands are covered.
> >
> > The fix of Syntastic should be pretty easy, as one can use the autocmd
> > pattern to exclude [cl]getexpr, right?
> 
> Syntastic is at the receiving end of this game, it just runs
> :lgetexpr.  All of a sudden :lgetexpr now triggers autocmds in other
> plugins, and there isn't anything syntastic can do about that.  Said
> plugins need to become aware of the new scope of their harmless little
> autocmds, become aware that they are now called from other plugins'
> code, and fix the calls, as you say, to exclude [cl]getexpr.  I'm sure
> they are all going to be fixed in no time. :)

Hm, can't you call noa lgetexpr ... ?

Best,
Christian
-- 
Jeder, der Unsterblichkeit auf seinem Wege errang, begreift nicht die
Anstrengungen eines andern, z.B. Bonaparte, der sie auf einem andern
sucht, und tadelt die Anstrengung.
-- Jean Paul

-- 
-- 
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: Patch 7.4.2299

[LCD 47]

On 2 September 2016, Ingo Karkat  wrote:
> On 09/02/2016 09:51 PM, LCD 47 wrote:
> > On 1 September 2016, Bram Moolenaar  wrote:
> >>
> >> Patch 7.4.2299 Problem:  QuickFixCmdPre and QuickFixCmdPost
> >> autocommands are not always triggered.  Solution:  Also trigger
> >> on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files:
> >> src/quickfix.c, src/testdir/test_quickfix.vim
> > [...]
> >
> > Sadly, this breaks the interaction of "syntastic" with all
> > plugins that hook to QuickFixCmdPre or QuickFixCmdPost.  An example
> > of such plugin is "ferret".  These plugins now have to be fixed to
> > be aware that they may be called from things like :lgetexpr.  I'd
> > argue that running QuickFixCmd* for :lgetexpr makes little sense,
> > since :lgetexpr is almost never called run interactively.  So, was
> > there an actual reason for this change, right before the release of
> > Vim 8?
>
> I use the QuickFixCmdPre/Post to automatically open / adapt the size
> of / close the quickfix window, and therefore appreciate that all
> quickfix-manipulating commands are covered.
>
> The fix of Syntastic should be pretty easy, as one can use the autocmd
> pattern to exclude [cl]getexpr, right?

Syntastic is at the receiving end of this game, it just runs
:lgetexpr.  All of a sudden :lgetexpr now triggers autocmds in other
plugins, and there isn't anything syntastic can do about that.  Said
plugins need to become aware of the new scope of their harmless little
autocmds, become aware that they are now called from other plugins'
code, and fix the calls, as you say, to exclude [cl]getexpr.  I'm sure
they are all going to be fixed in no time. :)

/lcd

-- 
-- 
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 7.4.2311

[Bram Moolenaar]

Patch 7.4.2311
Problem:Appveyor 64 bit build still using Python 3.4
Solution:   Switch to Python 3.5. (Ken Takata, closes #1032)
Files:  appveyor.yml, src/appveyor.bat


*** ../vim-7.4.2310/appveyor.yml2016-02-24 22:27:01.016713821 +0100
--- appveyor.yml2016-09-02 22:23:53.143479174 +0200
***
*** 26,34 
  test_script:
- cd src/testdir
  # Testing with MSVC gvim
- nmake -f Make_dos.mak VIMPROG=..\gvim
- nmake -f Make_dos.mak clean
  # Testing with MingW console version
- nmake -f Make_dos.mak VIMPROG=..\vim
  
! # vim: sw=2 sts=2 et ts=2 sr
--- 26,35 
  test_script:
- cd src/testdir
  # Testing with MSVC gvim
+   - path C:\Python35-x64;%PATH%
- nmake -f Make_dos.mak VIMPROG=..\gvim
- nmake -f Make_dos.mak clean
  # Testing with MingW console version
- nmake -f Make_dos.mak VIMPROG=..\vim
  
! # vim: sw=2 sts=2 et ts=8 sr
*** ../vim-7.4.2310/src/appveyor.bat2016-02-24 21:02:01.397693481 +0100
--- src/appveyor.bat2016-09-02 22:21:47.956546196 +0200
***
*** 16,22 
  :: with specified features without python.
  echo "Building MinGW 32bit GUI version"
  if "%FEATURE%" == "HUGE" (
! mingw32-make.exe -f Make_ming.mak OPTIMIZE=speed CHANNEL=yes GUI=yes 
IME=yes MBYTE=yes ICONV=yes DEBUG=no PYTHON_VER=27 DYNAMIC_PYTHON=yes 
PYTHON=C:\Python27 PYTHON3_VER=34 DYNAMIC_PYTHON3=yes PYTHON3=C:\Python34 
FEATURES=%FEATURE% || exit 1
  ) ELSE (
  mingw32-make.exe -f Make_ming.mak OPTIMIZE=speed GUI=yes IME=yes 
MBYTE=yes ICONV=yes DEBUG=no FEATURES=%FEATURE% || exit 1
  )
--- 16,22 
  :: with specified features without python.
  echo "Building MinGW 32bit GUI version"
  if "%FEATURE%" == "HUGE" (
! mingw32-make.exe -f Make_ming.mak OPTIMIZE=speed CHANNEL=yes GUI=yes 
IME=yes MBYTE=yes ICONV=yes DEBUG=no PYTHON_VER=27 DYNAMIC_PYTHON=yes 
PYTHON=C:\Python27 PYTHON3_VER=35 DYNAMIC_PYTHON3=yes PYTHON3=C:\Python35 
FEATURES=%FEATURE% || exit 1
  ) ELSE (
  mingw32-make.exe -f Make_ming.mak OPTIMIZE=speed GUI=yes IME=yes 
MBYTE=yes ICONV=yes DEBUG=no FEATURES=%FEATURE% || exit 1
  )
***
*** 31,37 
  :: GUI needs to be last, so that testing works
  echo "Building MSVC 64bit GUI Version"
  if "%FEATURE%" == "HUGE" (
! nmake -f Make_mvc2.mak DIRECTX=yes CPU=AMD64 CHANNEL=yes OLE=no GUI=yes 
IME=yes MBYTE=yes ICONV=yes DEBUG=no PYTHON_VER=27 DYNAMIC_PYTHON=yes 
PYTHON=C:\Python27-x64 PYTHON3_VER=34 DYNAMIC_PYTHON3=yes 
PYTHON3=C:\Python34-x64 FEATURES=%FEATURE% || exit 1
  ) ELSE (
  nmake -f Make_mvc2.mak CPU=AMD64 OLE=no GUI=yes IME=yes MBYTE=yes 
ICONV=yes DEBUG=no FEATURES=%FEATURE% || exit 1
  )
--- 31,37 
  :: GUI needs to be last, so that testing works
  echo "Building MSVC 64bit GUI Version"
  if "%FEATURE%" == "HUGE" (
! nmake -f Make_mvc2.mak DIRECTX=yes CPU=AMD64 CHANNEL=yes OLE=no GUI=yes 
IME=yes MBYTE=yes ICONV=yes DEBUG=no PYTHON_VER=27 DYNAMIC_PYTHON=yes 
PYTHON=C:\Python27-x64 PYTHON3_VER=35 DYNAMIC_PYTHON3=yes 
PYTHON3=C:\Python35-x64 FEATURES=%FEATURE% || exit 1
  ) ELSE (
  nmake -f Make_mvc2.mak CPU=AMD64 OLE=no GUI=yes IME=yes MBYTE=yes 
ICONV=yes DEBUG=no FEATURES=%FEATURE% || exit 1
  )
*** ../vim-7.4.2310/src/version.c   2016-09-02 22:18:45.462101097 +0200
--- src/version.c   2016-09-02 22:23:12.011829791 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2311,
  /**/


-- 
hundred-and-one symptoms of being an internet addict:
140. You'd rather catch a score on the web than watch the game as
 it is being played on tv.

 /// 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: [patch] fixed use of free memory with timers (bug introduced in Vim-7.4.2304)

[Bram Moolenaar]

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) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==11797== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
> info
> ==11797== Command: vim -u NONE -c call\ timer_start(0,\ "x")
> ==11797==
> ==11797== Invalid read of size 8
> ==11797==at 0x470ECA: remove_timer (ex_cmds2.c:1116)
> ==11797==by 0x4711CC: check_due_timer (ex_cmds2.c:1226)
> ==11797==by 0x5395BB: WaitForChar (os_unix.c:5399)
> ==11797==by 0x5343DE: mch_inchar (os_unix.c:425)
> ==11797==by 0x5D7C10: ui_inchar (ui.c:195)
> ==11797==by 0x4B993B: inchar (getchar.c:3057)
> ==11797==by 0x4B953B: vgetorpeek (getchar.c:2833)
> ==11797==by 0x4B758D: vgetc (getchar.c:1606)
> ==11797==by 0x4B7AD3: safe_vgetc (getchar.c:1802)
> ==11797==by 0x503F49: normal_cmd (normal.c:627)
> ==11797==by 0x6235CB: main_loop (main.c:1311)
> ==11797==by 0x622D55: vim_main2 (main.c:877)
> ==11797==  Address 0xdd18660 is 16 bytes inside a block of size 72 free'd
> ==11797==at 0x4C2BCEF: free (vg_replace_malloc.c:530)
> ==11797==by 0x4F3430: vim_free (misc2.c:1705)
> ==11797==by 0x470F66: free_timer (ex_cmds2.c:1132)
> ==11797==by 0x4711C0: check_due_timer (ex_cmds2.c:1225)
> ==11797==by 0x5395BB: WaitForChar (os_unix.c:5399)
> ==11797==by 0x5343DE: mch_inchar (os_unix.c:425)
> ==11797==by 0x5D7C10: ui_inchar (ui.c:195)
> ==11797==by 0x4B993B: inchar (getchar.c:3057)
> ==11797==by 0x4B953B: vgetorpeek (getchar.c:2833)
> ==11797==by 0x4B758D: vgetc (getchar.c:1606)
> ==11797==by 0x4B7AD3: safe_vgetc (getchar.c:1802)
> ==11797==by 0x503F49: normal_cmd (normal.c:627)
> ==11797==  Block was alloc'd at
> ==11797==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
> ==11797==by 0x4F28A0: lalloc (misc2.c:920)
> ==11797==by 0x4F27CB: alloc_clear (misc2.c:842)
> ==11797==by 0x470F81: create_timer (ex_cmds2.c:1143)
> ==11797==by 0x45EF7B: f_timer_start (evalfunc.c:12421)
> ==11797==by 0x44AFB0: call_internal_func (evalfunc.c:999)
> ==11797==by 0x5E620D: call_func (userfunc.c:1372)
> ==11797==by 0x5E408D: get_func_tv (userfunc.c:455)
> ==11797==by 0x5E9D8D: ex_call (userfunc.c:2981)
> ==11797==by 0x47BDC6: do_one_cmd (ex_docmd.c:2967)
> ==11797==by 0x478822: do_cmdline (ex_docmd.c:1110)
> ==11797==by 0x477E5E: do_cmdline_cmd (ex_docmd.c:715)
> (more errors after than)
> 
> Attached patch fixes it.

Thanks!

-- 
The coffee just wasn't strong enough to defend itself -- Tom Waits

 /// 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.

Patch 7.4.2310

[Bram Moolenaar]

Patch 7.4.2310 (after 7.4.2304)
Problem:Accessing freed memory when a timer does not repeat.
Solution:   Free after removing it. (Dominique Pelle)
Files:  src/ex_cmds2.c


*** ../vim-7.4.2309/src/ex_cmds2.c  2016-09-01 21:26:16.166308476 +0200
--- src/ex_cmds2.c  2016-09-02 21:58:28.240569008 +0200
***
*** 1222,1229 
}
else
{
-   free_timer(timer);
remove_timer(timer);
}
/* the callback may do anything, start all over */
break;
--- 1222,1229 
}
else
{
remove_timer(timer);
+   free_timer(timer);
}
/* the callback may do anything, start all over */
break;
*** ../vim-7.4.2309/src/version.c   2016-09-02 21:48:28.565811651 +0200
--- src/version.c   2016-09-02 22:18:39.406152683 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2310,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
139. You down your lunch in five minutes, at your desk, so you can
 spend the rest of the hour surfing the Net.

 /// 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: Patch 7.4.2299

[Ingo Karkat]

On 09/02/2016 09:51 PM, LCD 47 wrote:
> On 1 September 2016, Bram Moolenaar  wrote:
>>
>> Patch 7.4.2299
>> Problem:QuickFixCmdPre and QuickFixCmdPost autocommands are not always
>> triggered.
>> Solution:   Also trigger on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan)
>> Files:  src/quickfix.c, src/testdir/test_quickfix.vim
> [...]
> 
> Sadly, this breaks the interaction of "syntastic" with all plugins
> that hook to QuickFixCmdPre or QuickFixCmdPost.  An example of such
> plugin is "ferret".  These plugins now have to be fixed to be aware that
> they may be called from things like :lgetexpr.  I'd argue that running
> QuickFixCmd* for :lgetexpr makes little sense, since :lgetexpr is almost
> never called run interactively.  So, was there an actual reason for this
> change, right before the release of Vim 8?

I use the QuickFixCmdPre/Post to automatically open / adapt the size of
/ close the quickfix window, and therefore appreciate that all
quickfix-manipulating commands are covered.

The fix of Syntastic should be pretty easy, as one can use the autocmd
pattern to exclude [cl]getexpr, right?

-- regards, ingo

-- 
-- 
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.


signature.asc
Description: OpenPGP digital signature

Re: Patch 7.4.2299

[LCD 47]

On 1 September 2016, Bram Moolenaar  wrote:
> 
> Patch 7.4.2299
> Problem:QuickFixCmdPre and QuickFixCmdPost autocommands are not always
> triggered.
> Solution:   Also trigger on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan)
> Files:  src/quickfix.c, src/testdir/test_quickfix.vim
[...]

Sadly, this breaks the interaction of "syntastic" with all plugins
that hook to QuickFixCmdPre or QuickFixCmdPost.  An example of such
plugin is "ferret".  These plugins now have to be fixed to be aware that
they may be called from things like :lgetexpr.  I'd argue that running
QuickFixCmd* for :lgetexpr makes little sense, since :lgetexpr is almost
never called run interactively.  So, was there an actual reason for this
change, right before the release of Vim 8?

/lcd

-- 
-- 
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 7.4.2309

[Bram Moolenaar]

Patch 7.4.2309
Problem:Crash when doing tabnext in a BufUnload autocmd. (Dominique Pelle)
Solution:   When detecting that the tab page changed, don't just abort but
delete the window where w_buffer is NULL.
Files:  src/window.c, src/testdir/test_tabpage.vim


*** ../vim-7.4.2308/src/window.c2016-08-29 22:48:12.177105943 +0200
--- src/window.c2016-09-02 21:47:50.710142849 +0200
***
*** 2379,2385 
  #endif
close_buffer(win, win->w_buffer, free_buf ? DOBUF_UNLOAD : 0, TRUE);
  #ifdef FEAT_AUTOCMD
!   if (win_valid(win))
win->w_closing = FALSE;
  #endif
/* Make sure curbuf is valid. It can become invalid if 'bufhidden' is
--- 2379,2385 
  #endif
close_buffer(win, win->w_buffer, free_buf ? DOBUF_UNLOAD : 0, TRUE);
  #ifdef FEAT_AUTOCMD
!   if (win_valid_any_tab(win))
win->w_closing = FALSE;
  #endif
/* Make sure curbuf is valid. It can become invalid if 'bufhidden' is
***
*** 2399,2407 
getout(0);
  }
  
! /* Autocommands may have closed the window already, or closed the only
!  * other window or moved to another tab page. */
! else if (!win_valid(win) || last_window() || curtab != prev_curtab
|| close_last_window_tabpage(win, free_buf, prev_curtab))
return FAIL;
  
--- 2399,2416 
getout(0);
  }
  
! /* Autocommands may have moved to another tab page. */
! if (curtab != prev_curtab && win_valid_any_tab(win)
! && win->w_buffer == NULL)
! {
!   /* Need to close the window anyway, since the buffer is NULL. */
!   win_close_othertab(win, FALSE, prev_curtab);
!   return FAIL;
! }
! 
! /* Autocommands may have closed the window already or closed the only
!  * other window. */
! if (!win_valid(win) || last_window()
|| close_last_window_tabpage(win, free_buf, prev_curtab))
return FAIL;
  
***
*** 2492,2503 
  int   free_tp = FALSE;
  
  #ifdef FEAT_AUTOCMD
! if (win->w_closing || win->w_buffer->b_closing)
return; /* window is already being closed */
  #endif
  
! /* Close the link to the buffer. */
! close_buffer(win, win->w_buffer, free_buf ? DOBUF_UNLOAD : 0, FALSE);
  
  /* Careful: Autocommands may have closed the tab page or made it the
   * current tab page.  */
--- 2501,2515 
  int   free_tp = FALSE;
  
  #ifdef FEAT_AUTOCMD
! /* Get here with win->w_buffer == NULL when win_close() detects the tab
!  * page changed. */
! if (win->w_closing || (win->w_buffer != NULL && win->w_buffer->b_closing))
return; /* window is already being closed */
  #endif
  
! if (win->w_buffer != NULL)
!   /* Close the link to the buffer. */
!   close_buffer(win, win->w_buffer, free_buf ? DOBUF_UNLOAD : 0, FALSE);
  
  /* Careful: Autocommands may have closed the tab page or made it the
   * current tab page.  */
*** ../vim-7.4.2308/src/testdir/test_tabpage.vim2016-08-21 
19:07:14.265008108 +0200
--- src/testdir/test_tabpage.vim2016-09-02 21:42:10.277122715 +0200
***
*** 218,221 
--- 218,235 
bw!
  endfunction
  
+ func Test_tabnext_on_buf_unload()
+   " This once caused a crash
+   new
+   tabedit
+   tabfirst
+   au BufUnload  tabnext
+   q
+ 
+   while tabpagenr('$') > 1
+ quit
+   endwhile
+ endfunc
+ 
+ 
  " vim: shiftwidth=2 sts=2 expandtab
*** ../vim-7.4.2308/src/version.c   2016-09-02 20:03:17.493151155 +0200
--- src/version.c   2016-09-02 21:46:19.298942732 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2309,
  /**/


-- 
hundred-and-one symptoms of being an internet addict:
137. You decide to stay in college for an additional year or two,
 just so you can have the free Internet access.

 /// 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: Screen update issue with incsearch in latest code

[Christian Brabandt]

Hi Mike!

On Fr, 02 Sep 2016, Mike Williams wrote:

> Hi,
> 
> On 02/09/2016 12:22, Christian Brabandt wrote:
> >On Mi, 31 Aug 2016, Mike Williams wrote:
> >
> >>Hi,
> >>
> >>I pretty much lurk here these days but remember seeing some
> >>discussion on changes to do with incremental search.  I am seeing
> >>strange screen jumps with incremental search with the current
> >>version 7.4.2295.  This is on on Windows and linux.
> >>
> >>The following will reproduce the issue on Windows.  Start in the VIM
> >>source directory and invoke vim with gvim -u NONE -U NONE
> >>if_cscope.h. Next enable incsearch with ":set incsearch" and then
> >>start a search with "/Sto" - this should cause the display to jump
> >>to an enum near the end of the file.  At this point delete the o to
> >>leave "/St" as the search pattern and then hit return to finish the
> >>search.  I see VIM jumping back to the top of the file but with the
> >>cursor at the same position as for the search.  If then hit j to go
> >>down one line vim jumps back to the end of the file where the
> >>original search succeeded.
> >>
> >>The action that seems to trigger the unexpected jumps around the
> >>buffer is deleting characters from the search pattern.  It can be
> >>confusing as the screen doesn't initially display what you are
> >>expecting (with the cursor appearing beyond the end of a line
> >>sometimes) and then any cursor movement cause the display to jump
> >>again.
> >
> >Thanks for the almost perfect bug report (it just needed a patch to be
> >perfect ;))
> >
> >I could easily reproduce it. Turns out, that after backspacing, the view
> >will not be reset correctly. So we have to save some variables there.
> >
> >Please check the attached patch, which includes a test to fix this
> >behaviour.
> 
> It does fix my original problem but it has caused a new one.
> 
> With the same setup as above, delete all of pattern back to / and then
> hit return.  I get the expected "No previous regular expression" error.
> Then press return.  VIM should return back to the top of the file but
> instead displays the end of the file - until you move the cursor when it
> jumps back to the top of the file.  This does not happen without the
> patch applied.

good catch. updated patch attached. I added a test, but that didn't work 
as expected. Therefore the test is currently disabled. I verified 
manually, that either of  works as expected.

Best,
Christian
-- 
In der Politik errät sogar das Publikum stets das Listige und Feine;
nur das Große und Reine allein ist dazu gemacht, nicht geahnet zu
werden.
-- Jean Paul

-- 
-- 
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.
From a9553dd9ecbbbe7254250be28d7a05ee844e70c1 Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Fri, 2 Sep 2016 13:09:37 +0200
Subject: [PATCH] Save and restore position after  in search

patch 7.4.2259 introduced the possibility to jump to different matches
using / when 'incsearch' is set. This works by internally
setting the cursor position and saving and restoring the view for each
match.

Unfortunately, this introduced a regression, that when using  to
delete some characters from the search prompt and pressing enter, the
view would be restored to the initial view (when we started the search
command), while the cursor might end up still on a different line (not
even being visible).

Therefore, let's just save the current view on deleteing characters from
the command line, so that it will be correctly restored on pressing
enter and add a test to verify, this actually works.
---
 src/ex_getln.c  | 27 ++-
 src/testdir/test_search.vim | 25 +
 2 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/src/ex_getln.c b/src/ex_getln.c
index 110a95a..4fb4c73 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -179,15 +179,20 @@ getcmdline(
 #ifdef FEAT_SEARCH_EXTRA
 pos_T	old_cursor;
 colnr_T	old_curswant;
+colnr_T init_curswant = curwin->w_curswant;
 colnr_T	old_leftcol;
+colnr_T init_leftcol = curwin->w_leftcol;
 linenr_T	old_topline;
+linenr_Tinit_topline = curwin->w_topline;
 pos_T   cursor_start;
 pos_T   match_start = curwin->w_cursor;
 pos_T   match_end;
 # ifdef FEAT_DIFF
 int		old_topfill;
+int init_topfill = curwin->w_topfill;
 # endif
 linenr_T	old_botline;
+linenr_T	init_botline = curwin->w_botline;
 int		did_incsearch = FALSE;
 int		incsearch_postponed = FALSE;
 #endif
@@ -1006,13 +1011,33 @@ getcmdlin

Patch 7.4.2308

[Bram Moolenaar]

Patch 7.4.2308
Problem:Old charsearch test still listed in Makefile.
Solution:   Remove the line.
Files:  src/testdir/Make_all.mak


*** ../vim-7.4.2307/src/testdir/Make_all.mak2016-09-02 19:50:08.432097742 
+0200
--- src/testdir/Make_all.mak2016-09-02 20:01:28.602113830 +0200
***
*** 83,89 
test_autoformat_join.out \
test_breakindent.out \
test_changelist.out \
-   test_charsearch.out \
test_close_count.out \
test_command_count.out \
test_comparators.out \
--- 83,88 
*** ../vim-7.4.2307/src/version.c   2016-09-02 19:50:08.440097674 +0200
--- src/version.c   2016-09-02 20:02:48.601406499 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2308,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
136. You decide to stay in a low-paying job teaching just for the
 free Internet access.

 /// 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: [bug] vim-7.4.2305 crashes in bugIsChanged with NULL buf pointer

[Bram Moolenaar]

Dominique Pellé wrote:

> The attached script causes vim-7.4.2305 to crash:
> 
> $ cat crash.vim
> new
> tabedit
> tabfirst
> au BufUnload  tabnext
> q
> 
> $ vim -u NONE -S crash.vim
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> Segmentation fault (core dumped)
> 
> 3518│ int
> 3519│ bufIsChanged(buf_T *buf)
> 3520│ {
> 3521│ return
> 3522│ #ifdef FEAT_QUICKFIX
> 3523│ !bt_dontwrite(buf) &&
> 3524│ #endif
> 3525├>(buf->b_changed || file_ff_differs(buf, TRUE));
> 3526│ }
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x005eee37 in bufIsChanged (buf=0x0) at undo.c:3525
> (gdb) bt
> #0  0x005eee37 in bufIsChanged (buf=0x0) at undo.c:3525
> #1  0x0058cd9b in draw_tabline () at screen.c:10407
> #2  0x00579548 in update_screen (type=40) at screen.c:638
> #3  0x006416dd in main_loop (cmdwin=0, noexmode=0) at main.c:1211
> #4  0x006410b7 in vim_main2 () at 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 first bad commit
> commit e59215c7dcae17b03daf39517560cfaa03314f5a
> Author: Bram Moolenaar 
> Date:   Sun Aug 14 19:08:45 2016 +0200
> 
> patch 7.4.2212
> Problem:Mark " is not set when closing a window in another tab. 
> (Guraga)
> Solution:   Check all tabs for the window to be valid. (based on patch by
> Hirohito Higashi, closes #974)
> ==
> 
> Crash was found by fuzzing with American fuzzy lop.

Easy to reproduce, thanks.

-- 
hundred-and-one symptoms of being an internet addict:
135. You cut classes or miss work so you can stay home and browse the web.

 /// 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: Convert test_marks to a new style test

[Bram Moolenaar]

Yegappan wrote:

> On Thu, Sep 1, 2016 at 1:10 PM, Bram Moolenaar  wrote:
> >
> > Yegappan wrote:
> >
> >> >> The attached patch converts the test_marks test from old style to new 
> >> >> style.
> >> >
> >> > Thanks, I'll look into it soon.
> >> >
> >>
> >> I have converted a few more tests to new style tests.
> >
> > The test_charsearch.vim file is missing.
> >
> 
> I am attaching an updated patch (with a few more old style tests
> converted to new style tests).

Thanks!

-- 
"The sun oozed over the horizon, shoved aside darkness, crept along the
greensward, and, with sickly fingers, pushed through the castle window,
revealing the pillaged princess, hand at throat, crown asunder, gaping
in frenzied horror at the sated, sodden amphibian lying beside her,
disbelieving the magnitude of the frog's deception, screaming madly,
"You lied!"
- Winner of the Bulwer-Lytton contest (San Jose State University),
  wherein one writes only the first line of a bad novel

 /// 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.

Patch 7.4.2307

[Bram Moolenaar]

Patch 7.4.2307
Problem:Several tests are old style.
Solution:   Turn them into new style tests. (Yegappan Lakshmanan)
Files:  src/testdir/Make_all.mak, src/testdir/test102.in,
src/testdir/test102.ok, src/testdir/test46.in,
src/testdir/test46.ok, src/testdir/test81.in,
src/testdir/test81.ok, src/testdir/test_charsearch.in,
src/testdir/test_charsearch.ok, src/testdir/test_charsearch.vim,
src/testdir/test_fnameescape.vim, src/testdir/test_substitute.vim,
src/Makefile


*** ../vim-7.4.2306/src/testdir/Make_all.mak2016-09-01 22:19:22.540166008 
+0200
--- src/testdir/Make_all.mak2016-09-02 19:39:33.929523113 +0200
***
*** 42,48 
test43.out \
test44.out \
test45.out \
-   test46.out \
test48.out \
test51.out \
test53.out \
--- 42,47 
***
*** 64,70 
test77.out \
test79.out \
test80.out \
-   test81.out \
test82.out \
test84.out \
test88.out \
--- 63,68 
***
*** 77,83 
test98.out \
test99.out \
test101.out \
-   test102.out \
test103.out \
test104.out \
test107.out \
--- 75,80 
***
*** 157,167 
--- 154,166 
test_bufwintabinfo.res \
test_cdo.res \
test_channel.res \
+   test_charsearch.res \
test_cmdline.res \
test_cscope.res \
test_diffmode.res \
test_digraph.res \
test_farsi.res \
+   test_fnameescape.res \
test_gn.res \
test_gui.res \
test_hardcopy.res \
***
*** 185,190 
--- 184,190 
test_startup.res \
test_startup_utf8.res \
test_stat.res \
+   test_substitute.res \
test_syntax.res \
test_textobjects.res \
test_undo.res \
*** ../vim-7.4.2306/src/testdir/test102.in  2014-07-30 13:20:35.719622565 
+0200
--- src/testdir/test102.in  1970-01-01 01:00:00.0 +0100
***
*** 1,13 
- Test if fnameescape is correct for special chars like !
- 
- STARTTEST
- :so small.vim
- :%d
- :let fname = 'Xspa ce'
- :try | exe "w! " . fnameescape(fname) | put='Space' | endtry 
- :let fname = 'Xemark!'
- :try | exe "w! " . fnameescape(fname) | put='ExclamationMark' | endtry
- :w! test.out
- :qa!
- ENDTEST
- 
--- 0 
*** ../vim-7.4.2306/src/testdir/test102.ok  2013-11-12 05:28:08.0 
+0100
--- src/testdir/test102.ok  1970-01-01 01:00:00.0 +0100
***
*** 1,3 
- 
- Space
- ExclamationMark
--- 0 
*** ../vim-7.4.2306/src/testdir/test46.in   2010-05-15 13:04:10.0 
+0200
--- src/testdir/test46.in   1970-01-01 01:00:00.0 +0100
***
*** 1,27 
- Tests for multi-line regexps with ":s". vim: set ft=vim :
- 
- STARTTEST
- :" test if replacing a line break works with a back reference
- :/^1/,/^2/s/\n\(.\)/ \1/
- :" test if inserting a line break works with a back reference
- :/^3/,/^4/s/\(.\)$/\r\1/
- :" test if replacing a line break with another line break works
- :/^5/,/^6/s/\(\_d\{3}\)/x\1x/
- :/^1/,$w! test.out
- :qa!
- ENDTEST
- 
- 1 aa
- bb
- cc
- 2 dd
- ee
- 3 ef
- gh
- 4 ij
- 5 a8
- 8b c9
- 9d
- 6 e7
- 77f
- x
--- 0 
*** ../vim-7.4.2306/src/testdir/test46.ok   2010-05-15 13:04:10.0 
+0200
--- src/testdir/test46.ok   1970-01-01 01:00:00.0 +0100
***
*** 1,13 
- 1 aa bb cc 2 dd ee
- 3 e
- f
- g
- h
- 4 i
- j
- 5 ax8
- 8xb cx9
- 9xd
- 6 ex7
- 7x7f
- x
--- 0 
*** ../vim-7.4.2306/src/testdir/test81.in   2011-07-15 13:25:00.0 
+0200
--- src/testdir/test81.in   1970-01-01 01:00:00.0 +0100
***
*** 1,22 
- Test for t movement command and 'cpo-;' setting
- 
- STARTTEST
- :set nocompatible viminfo+=nviminfo
- :set cpo-=;
- /firstline/
- j0tt;D
- 0fz;D
- $Fy;D
- $Ty;D:set cpo+=;
- j0tt;;D
- $Ty;;D:?firstline?+1,$w! test.out
- :qa!
- ENDTEST
- 
- firstline
- aaa two three four
- zzz
- yyy   
- bbb yee yoo four
- ccc two three four
- ddd yee yoo four
--- 0 
*** ../vim-7.4.2306/src/testdir/test81.ok   2011-07-15 13:14:27.0 
+0200
--- src/testdir/test81.ok   1970-01-01 01:00:00.0 +0100
***
*** 1,6 
- aaa two
- z
- y
- bbb y
- ccc
- ddd yee y
--- 0 
*** ../vim-7.4.2306/src/testdir/test_charsearch.in  2016-02-20 
15:10:46.693695130 +0100
--- src/testdir/test_charsearch.in  1970-01-01 01:00:00.0 +0100
***
*** 1,26 
- Test for character searches
- 
- STARTTEST
- :so small.vim
- :" check that "fe" and ";" work
- /^X
- ylfep;;p,,p:
- :" check that save/restore works
- /^Y
- ylfep:let csave = getcharsearch()
- fip:call setcharsearch(csave)
- ;p;p:
- :" check that setcharsearch() changes the settings.
- /^Z
- ylf

Patch 7.4.2306

[Bram Moolenaar]

Patch 7.4.2306
Problem:Default value for 'langremap' is wrong.
Solution:   Set the right value. (Jürgen Krämer)  Add a test.
Files:  src/option.c, src/testdir/test_mapping.vim


*** ../vim-7.4.2305/src/option.c2016-08-29 22:48:12.157106115 +0200
--- src/option.c2016-09-02 19:26:03.148482679 +0200
***
*** 1711,1717 
  #else
(char_u *)NULL, PV_NONE,
  #endif
!   {(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
  {"laststatus",  "ls",   P_NUM|P_VI_DEF|P_RALL,
  #ifdef FEAT_WINDOWS
(char_u *)&p_ls, PV_NONE,
--- 1711,1717 
  #else
(char_u *)NULL, PV_NONE,
  #endif
!   {(char_u *)TRUE, (char_u *)0L} SCRIPTID_INIT},
  {"laststatus",  "ls",   P_NUM|P_VI_DEF|P_RALL,
  #ifdef FEAT_WINDOWS
(char_u *)&p_ls, PV_NONE,
*** ../vim-7.4.2305/src/testdir/test_mapping.vim2016-08-21 
17:44:57.440487201 +0200
--- src/testdir/test_mapping.vim2016-09-02 19:27:44.363612034 +0200
***
*** 72,77 
--- 72,85 
set nolangremap
call assert_equal(1, &langnoremap)
  
+   " check default values
+   set langnoremap&
+   call assert_equal(0, &langnoremap)
+   call assert_equal(1, &langremap)
+   set langremap&
+   call assert_equal(0, &langnoremap)
+   call assert_equal(1, &langremap)
+ 
" langmap should not apply in insert mode, 'langremap' doesn't matter
set langmap=+{ nolangremap
call feedkeys("Go+\", "xt")
*** ../vim-7.4.2305/src/version.c   2016-09-01 22:19:22.544165975 +0200
--- src/version.c   2016-09-02 19:29:05.214916953 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2306,
  /**/

-- 
Birthdays are healthy.  The more you have them, the longer you live.

 /// 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: Patch 7.4.2236

[Bram Moolenaar]

Jürgen Krämer wrote:

> Bram Moolenaar schrieb am 21.08.2016 um 17:45:
> > 
> > Patch 7.4.2236
> > Problem:The 'langnoremap' option leads to double negatives.  And it does
> > not work for the last character of a mapping.
> > Solution:   Add 'langremap' with the opposite value.  Keep 'langnoremap' for
> > backwards compatibility.  Make it work for the last character 
> > of a
> > mapping.  Make the test work.
> > Files:  runtime/doc/options.txt, runtime/defaults.vim, src/option.c,
> > src/option.h, src/macros.h, src/testdir/test_mapping.vim
> >
> [...]
> > 
> > *** ../vim-7.4.2235/src/option.c2016-08-14 19:54:16.328930182 +0200
> > --- src/option.c2016-08-21 16:40:47.818509362 +0200
> > ***
> > *** 1705,1710 
> > --- 1705,1717 
> > (char_u *)NULL, PV_NONE,
> >   #endif
> > {(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
> > + {"langremap",  "lrm",   P_BOOL|P_VI_DEF,
> > + #ifdef FEAT_LANGMAP
> > +   (char_u *)&p_lrm, PV_NONE,
> > + #else
> > +   (char_u *)NULL, PV_NONE,
> > + #endif
> > +   {(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
> >   {"laststatus",  "ls",   P_NUM|P_VI_DEF|P_RALL,
> >   #ifdef FEAT_WINDOWS
> > (char_u *)&p_ls, PV_NONE,
> > ***
> [...]
> 
> the default for 'langremap' is wrong; it should default to "on". Patch
> attached.

Ah, stupid mistake.  Thanks!

-- 
There are three kinds of persons: Those who can count and those who can't.

 /// 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: Patch 7.4.2302

[Bram Moolenaar]

Ken Takata wrote:

> 2016/9/2 Fri 3:51:35 UTC+9 Bram Moolenaar wrote:
> > Patch 7.4.2302
> > Problem:Default interface versions for MS-Windows are outdated.
> > Solution:   Use Active Perl 5.24, Python 3.5.2.  Could only make it work 
> > with
> > Ruby 1.9.2.
> > Files:  src/bigvim.bat, src/bigvim64.bat
> 
> As I wrote in INSTALLpc.txt, you need a hack to link with recent Ruby.
> (If you use a binary from rubyinstaller.org .)
> You need to generate config.h from Ruby's source code. Also you need to set
> RUBY_MSVCRT_NAME=msvcrt .
> The build script in vim-win32-installer uses this hack.
> https://github.com/vim/vim-win32-installer/blob/master/appveyor.bat#L113-L122
> https://github.com/vim/vim-win32-installer/blob/master/appveyor.bat#L163

I tried part of this and it failed.  I'll give it another try.

> BTW, which ruby binary do you use?  Maybe ruby-1.9.2-p136-i386-mswin32.zip
> form http://www.garbagecollect.jp/ruby/mswin32/en/download/release.html ?
> If you use this, you also need to set RUBY_VER_LONG=1.9.1 instead of 1.9.2.
> Because Ruby 1.9.2's API version is 1.9.1 and RUBY_VER_LONG is used for
> specifying API version.

Yes, that's what I used before.  I renamed the directory.

> I think the name RUBY_VER_LONG is confusing. Renaming to RUBY_API_VER_LONG
> makes the thing clearer. (But the name is long.)

Yes, that's better.

-- 
Never eat yellow snow.

 /// 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.

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

[Dominique Pellé]

Hi

The attached script causes vim-7.4.2305 to crash:

$ cat crash.vim
new
tabedit
tabfirst
au BufUnload  tabnext
q

$ vim -u NONE -S crash.vim
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault (core dumped)

3518│ int
3519│ bufIsChanged(buf_T *buf)
3520│ {
3521│ return
3522│ #ifdef FEAT_QUICKFIX
3523│ !bt_dontwrite(buf) &&
3524│ #endif
3525├>(buf->b_changed || file_ff_differs(buf, TRUE));
3526│ }

Program received signal SIGSEGV, Segmentation fault.
0x005eee37 in bufIsChanged (buf=0x0) at undo.c:3525
(gdb) bt
#0  0x005eee37 in bufIsChanged (buf=0x0) at undo.c:3525
#1  0x0058cd9b in draw_tabline () at screen.c:10407
#2  0x00579548 in update_screen (type=40) at screen.c:638
#3  0x006416dd in main_loop (cmdwin=0, noexmode=0) at main.c:1211
#4  0x006410b7 in vim_main2 () at 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 first bad commit
commit e59215c7dcae17b03daf39517560cfaa03314f5a
Author: Bram Moolenaar 
Date:   Sun Aug 14 19:08:45 2016 +0200

patch 7.4.2212
Problem:Mark " is not set when closing a window in another tab. (Guraga)
Solution:   Check all tabs for the window to be valid. (based on patch by
Hirohito Higashi, closes #974)
==

Crash was found by fuzzing with American fuzzy lop.

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.


crash.vim
Description: Binary data

Re: Patch 7.4.2302

[Ken Takata]

Hi Bram,

2016/9/2 Fri 3:51:35 UTC+9 Bram Moolenaar wrote:
> Patch 7.4.2302
> Problem:Default interface versions for MS-Windows are outdated.
> Solution:   Use Active Perl 5.24, Python 3.5.2.  Could only make it work with
> Ruby 1.9.2.
> Files:  src/bigvim.bat, src/bigvim64.bat

As I wrote in INSTALLpc.txt, you need a hack to link with recent Ruby.
(If you use a binary from rubyinstaller.org .)
You need to generate config.h from Ruby's source code. Also you need to set
RUBY_MSVCRT_NAME=msvcrt .
The build script in vim-win32-installer uses this hack.
https://github.com/vim/vim-win32-installer/blob/master/appveyor.bat#L113-L122
https://github.com/vim/vim-win32-installer/blob/master/appveyor.bat#L163

BTW, which ruby binary do you use?  Maybe ruby-1.9.2-p136-i386-mswin32.zip
form http://www.garbagecollect.jp/ruby/mswin32/en/download/release.html ?
If you use this, you also need to set RUBY_VER_LONG=1.9.1 instead of 1.9.2.
Because Ruby 1.9.2's API version is 1.9.1 and RUBY_VER_LONG is used for
specifying API version.

I think the name RUBY_VER_LONG is confusing. Renaming to RUBY_API_VER_LONG
makes the thing clearer. (But the name is long.)

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.

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

[Bram Moolenaar]

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 norm! g<')
> > > :echo empty(b)
> > > 1
> > > :norm! g<
> > > (does not output anything)
> > 
> > That's not a bug, the g< output is not redirected.
> > 
> > If you are looking for a way to grab previously listed text we could add
> > some way specifically for that.  Changing g< to redirect is not a good
> > idea, it scrolls back and would double the redirected lines.
> 
> Just as an addendum, while I realize, that not being able to redirect g< 
> is no bug, that fact that afterwards g< does not return anything is 
> still a bug, isn't it?

Not really.  It shows the last page of the last output.  Since you made
an output that shows nothing, that's what it shows again.  It's not
useful, but trying to keep the last useful page is a bit complicated.
It hasn't come up in normal use, so it should be OK.

-- 
hundred-and-one symptoms of being an internet addict:
132. You come back and check this list every half-hour.

 /// 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: Screen update issue with incsearch in latest code

[Mike Williams]

Hi,

On 02/09/2016 12:22, Christian Brabandt wrote:

On Mi, 31 Aug 2016, Mike Williams wrote:


Hi,

I pretty much lurk here these days but remember seeing some
discussion on changes to do with incremental search.  I am seeing
strange screen jumps with incremental search with the current
version 7.4.2295.  This is on on Windows and linux.

The following will reproduce the issue on Windows.  Start in the VIM
source directory and invoke vim with gvim -u NONE -U NONE
if_cscope.h. Next enable incsearch with ":set incsearch" and then
start a search with "/Sto" - this should cause the display to jump
to an enum near the end of the file.  At this point delete the o to
leave "/St" as the search pattern and then hit return to finish the
search.  I see VIM jumping back to the top of the file but with the
cursor at the same position as for the search.  If then hit j to go
down one line vim jumps back to the end of the file where the
original search succeeded.

The action that seems to trigger the unexpected jumps around the
buffer is deleting characters from the search pattern.  It can be
confusing as the screen doesn't initially display what you are
expecting (with the cursor appearing beyond the end of a line
sometimes) and then any cursor movement cause the display to jump
again.


Thanks for the almost perfect bug report (it just needed a patch to be
perfect ;))

I could easily reproduce it. Turns out, that after backspacing, the view
will not be reset correctly. So we have to save some variables there.

Please check the attached patch, which includes a test to fix this
behaviour.


It does fix my original problem but it has caused a new one.

With the same setup as above, delete all of pattern back to / and then
hit return.  I get the expected "No previous regular expression" error.
Then press return.  VIM should return back to the top of the file but
instead displays the end of the file - until you move the cursor when it
jumps back to the top of the file.  This does not happen without the
patch applied.

HTH - TTFN

Mike
--
There are a thousand languages, but a smile speaks them all.
[Visit us at Labelexpo Americas 2016, stand 5931] 


--
--
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: Screen update issue with incsearch in latest code

[Christian Brabandt]

On Mi, 31 Aug 2016, Mike Williams wrote:

> Hi,
> 
> I pretty much lurk here these days but remember seeing some
> discussion on changes to do with incremental search.  I am seeing
> strange screen jumps with incremental search with the current
> version 7.4.2295.  This is on on Windows and linux.
> 
> The following will reproduce the issue on Windows.  Start in the VIM
> source directory and invoke vim with gvim -u NONE -U NONE
> if_cscope.h. Next enable incsearch with ":set incsearch" and then
> start a search with "/Sto" - this should cause the display to jump
> to an enum near the end of the file.  At this point delete the o to
> leave "/St" as the search pattern and then hit return to finish the
> search.  I see VIM jumping back to the top of the file but with the
> cursor at the same position as for the search.  If then hit j to go
> down one line vim jumps back to the end of the file where the
> original search succeeded.
> 
> The action that seems to trigger the unexpected jumps around the
> buffer is deleting characters from the search pattern.  It can be
> confusing as the screen doesn't initially display what you are
> expecting (with the cursor appearing beyond the end of a line
> sometimes) and then any cursor movement cause the display to jump
> again.

Thanks for the almost perfect bug report (it just needed a patch to be 
perfect ;))

I could easily reproduce it. Turns out, that after backspacing, the view 
will not be reset correctly. So we have to save some variables there.

Please check the attached patch, which includes a test to fix this 
behaviour.

Best,
Christian
-- 
Wer weiß denn, ob das Leben nicht das Totsein ist und das Totsein
Leben
-- Euripides (580-406 v. Chr.)

-- 
-- 
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.
From 6e0de09303e580ef77c41bea61be91910eed1235 Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Fri, 2 Sep 2016 13:09:37 +0200
Subject: [PATCH] Save and restore position after  in search

patch 7.4.2259 introduced the possibility to jump to different matches
using / when 'incsearch' is set. This works by internally
setting the cursor position and saving and restoring the view for each
match.

Unfortunately, this introduced a regression, that when using  to
delete some characters from the search prompt and pressing enter, the
view would be restored to the initial view (when we started the search
command), while the cursor might end up still on a different line (not
even being visible).

Therefore, let's just save the current view on deleteing characters from
the command line, so that it will be correctly restored on pressing
enter and add a test to verify, this actually works.
---
 src/ex_getln.c  | 8 
 src/testdir/test_search.vim | 8 
 2 files changed, 16 insertions(+)

diff --git a/src/ex_getln.c b/src/ex_getln.c
index 110a95a..369acb2 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -1011,6 +1011,14 @@ getcmdline(
 		{
 			old_cursor = match_start;
 			decl(&old_cursor);
+			/* save view settings, so that the screen
+			 * won't be restored at the wrong position */
+			old_leftcol = curwin->w_leftcol;
+			old_topline = curwin->w_topline;
+# ifdef FEAT_DIFF
+			old_topfill = curwin->w_topfill;
+# endif
+			old_botline = curwin->w_botline;
 		}
 #endif
 		redrawcmd();
diff --git a/src/testdir/test_search.vim b/src/testdir/test_search.vim
index 6e51460..0abb7fd 100644
--- a/src/testdir/test_search.vim
+++ b/src/testdir/test_search.vim
@@ -235,8 +235,16 @@ func Test_search_cmdline2()
   " go to previous match (on line 2)
   call feedkeys("/the\\\", 'tx')
   call assert_equal('  2 these', getline('.'))
+  " Test 2: keep the view,
+  " after deleting a character from the search cmd
+  call setline(1, ['  1', '  2 these', '  3 the', '  4 their', '  5 there', '  6 their', '  7 the', '  8 them', '  9 these', ' 10 foobar'])
+  resize 5
+  1
+  call feedkeys("/foo\\", 'tx')
+  call assert_equal({'lnum': 10, 'leftcol': 0, 'col': 4, 'topfill': 0, 'topline': 6, 'coladd': 0, 'skipcol': 0, 'curswant': 4}, winsaveview())
 
   " clean up
+  set noincsearch
   call test_disable_char_avail(0)
   bw!
 endfunc
-- 
2.1.4

Re: Patch 7.4.2299

[Bram Moolenaar]

Yegappan wrote:

> On Thu, Sep 1, 2016 at 6:46 AM, Bram Moolenaar  wrote:
> >
> > Patch 7.4.2299
> > Problem:QuickFixCmdPre and QuickFixCmdPost autocommands are not always
> > triggered.
> > Solution:   Also trigger on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan)
> > Files:  src/quickfix.c, src/testdir/test_quickfix.vim
> >
> 
> The update to the autocmd.txt help file is missing in this patch.

Yeah, it will be in the runtime updates.

-- 
Don't drink and drive.  You might hit a bump and spill your beer.

 /// 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: [bug] g< does not work with execute()/redir

[Christian Brabandt]

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 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)
> 
> That's not a bug, the g< output is not redirected.
> 
> If you are looking for a way to grab previously listed text we could add
> some way specifically for that.  Changing g< to redirect is not a good
> idea, it scrolls back and would double the redirected lines.

Just as an addendum, while I realize, that not being able to redirect g< 
is no bug, that fact that afterwards g< does not return anything is 
still a bug, isn't it?

Best,
Christian
-- 
In der Ehe schämt man sich mehr, der Gattin die geistige Liebe zu
offenbaren als die körperliche; vor der Ehe natürlich umgekehrt.
-- Jean Paul

-- 
-- 
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: Patch 7.4.2236

['Jürgen Krämer' via vim_dev]

Hi Bram,

Bram Moolenaar schrieb am 21.08.2016 um 17:45:
> 
> Patch 7.4.2236
> Problem:The 'langnoremap' option leads to double negatives.  And it does
> not work for the last character of a mapping.
> Solution:   Add 'langremap' with the opposite value.  Keep 'langnoremap' for
> backwards compatibility.  Make it work for the last character of a
> mapping.  Make the test work.
> Files:  runtime/doc/options.txt, runtime/defaults.vim, src/option.c,
> src/option.h, src/macros.h, src/testdir/test_mapping.vim
>
[...]
> 
> *** ../vim-7.4.2235/src/option.c  2016-08-14 19:54:16.328930182 +0200
> --- src/option.c  2016-08-21 16:40:47.818509362 +0200
> ***
> *** 1705,1710 
> --- 1705,1717 
>   (char_u *)NULL, PV_NONE,
>   #endif
>   {(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
> + {"langremap",  "lrm",   P_BOOL|P_VI_DEF,
> + #ifdef FEAT_LANGMAP
> + (char_u *)&p_lrm, PV_NONE,
> + #else
> + (char_u *)NULL, PV_NONE,
> + #endif
> + {(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
>   {"laststatus",  "ls",   P_NUM|P_VI_DEF|P_RALL,
>   #ifdef FEAT_WINDOWS
>   (char_u *)&p_ls, PV_NONE,
> ***
[...]

the default for 'langremap' is wrong; it should default to "on". Patch
attached.

Regards,
Jürgen

-- 
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

-- 
-- 
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.
diff --git a/src/option.c b/src/option.c
index c956deb..d75f06a 100644
--- a/src/option.c
+++ b/src/option.c
@@ -1722,7 +1722,7 @@ static struct vimoption options[] =
 #else
(char_u *)NULL, PV_NONE,
 #endif
-   {(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
+   {(char_u *)TRUE, (char_u *)0L} SCRIPTID_INIT},
 {"laststatus",  "ls",   P_NUM|P_VI_DEF|P_RALL,
 #ifdef FEAT_WINDOWS
(char_u *)&p_ls, PV_NONE,