Re: [vim/vim] test_tabpage: Check in Test_tabpage_with_tab_modifier (#1042)

[h_east]

Hi James,

2016-9-6(Tue) 12:11:28 UTC+9 James McCoy:
> If the tests are run in a (fake)root environment,
> 
> Test_tabpage_with_tab_modifier fails when run through test_alot.vim.
> 
> This is due to  being set by the modeline of the help files,
> 
> and modelines are disabled when running as (fake)root.
> 
> 
> Using  instead avoids the fickleness of the way  is
> 
> being set.
> 
> 
> This was found while attempting to update the Debian packaging of Vim,
> 
> but can be boiled down to:
> 
> 
> $ fakeroot make -C src/testdir test_alot.res
> 
> 
> 
> You can view, comment on, or merge this pull request online at:
> 
>   https://github.com/vim/vim/pull/1042
> 
> Commit Summary
> 
>   test_tabpage: Check  in Test_tabpage_with_tab_modifier
> 
> 
> File Changes
> 
>   
> M
> src/testdir/test_tabpage.vim
> (2)
>   
> 
> 
> Patch Links:
> 
>   https://github.com/vim/vim/pull/1042.patch
>   https://github.com/vim/vim/pull/1042.diff

I am writer of Test_tabpage_with_tab_modifier().
Ah, You are right.
Thanks for the follow up.
--
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.

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

[Ken Takata]

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) 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 "C:/MinGW/msys/1.0/sh.exe", a unix shell, and so all such
> >> if-statements fail.
> >>
> >> This can be sidestepped by setting SHELL=cmd.exe on the make command
> >> line but then unix utilities such as "rm" are used instead of "del" and
> >> DIRSLASH is set to "/" instead of "\" and so vim.exe cannot be launched
> >> to run the test (cmd.exe does not accept forward slashes in paths).
> >> This new problem is caused by an incorrectly constructed if-test in the
> >> makefile:
> >>
> >> ifneq(sh.exe,$(SHELL))
> >>
> >> followed by unix-style definitions.  I think that the author had
> >> intended this
> >>
> >> ifeq(sh.exe, $(SHELL))
> > No, this is confusing but intended. Please try the following Makefile:
> >
> >all:
> > echo $(SHELL)
> >
> > If you run mingw32-make.exe (not make.exe) on cmd.exe, you will see the
> > following result:
> >
> >C:\tmp>\msys32\mingw32\bin\mingw32-make.exe
> >echo sh.exe
> >sh.exe
> No, this is not what I see.  I see "C:/MinGW/msys/1.0/sh.exe"
> >
> > Other results are...
> >
> > make.exe on cmd.exe:
> >
> >C:\tmp>\msys32\usr\bin\make.exe
> >echo /bin/sh
> >make: echo: Command not found
> >make: *** [Makefile.mingw:2: all] Error 127
> >
> > This doesn't work as expected.
> >
> > mingw32-make.exe on bash.exe:
> >
> >$ mingw32-make
> >echo C:/msys32/usr/bin/sh.exe
> >C:/msys32/usr/bin/sh.exe
> >
> > make.exe on bash.exe:
> >
> >$ make
> >echo /bin/sh
> >/bin/sh
> >
> >
> > Normally, mingw32-make should be used when the shell is cmd.exe.
> > (I don't know when the shell is bash.exe.)
> 
> My apologies for not being clearer.  I am running mingw32-make.  I did 
> exactly what you suggested above and got "C:/MinGW/msys/1.0/sh.exe" for 
> SHELL. In the interest of full disclosure, I'm using TDM-GCC-64 to build 
> Vim and run the tests. It does not include a unix shell.  Its version of 
> make apparently looks for and finds one in my MinGW/msys installation 
> which is on my path.

Ah, reproduced.
When I add the msys2 directory to the PATH, mingw32-make finds sh.exe and
the SHELL becomes a full path of the sh.exe (e.g. c:/msys64/usr/bin/sh.exe)
even if I run mingw32-make on cmd.exe, and the sh.exe is used as a shell.

If mingw32-make cannot find sh.exe from the PATH, the SHELL is set to "sh.exe"
(without path) and actually cmd.exe is used as a shell.

So the following condition is still correct (if a user doesn't set the SHELL
explicitly):

  ifneq (sh.exe, $(SHELL))
  # The shell is sh.exe.
  else
  # The shell is cmd.exe.
  endif


> Given all your examples above, if the makefile must include unix shell 
> support, wouldn't the better implementation have been:
>ifeq("cmd.exe", $(SHELL))
> followed by the DOS definitions?  This covers SHELL being "sh", "/bin/sh" or 
> whatever.  That said, I still claim that
>ifeq("cmd.exe", $(notdir $(SHELL)))
> is the right thing to do in case the value of SHELL includes a path.
> 
> Again, I see this discussion if ifneq/ifeq statements as somewhat irrelevant 
> since the "if exist" statements in the makefile assume/demand a cmd shell.

Yeah, I understand that the actual problem is that "if exist ..." doesn't work
when sh.exe is used as a shell, but I wanted to make clear about the SHELL
condition at first.


> >> This is all interesting but mostly irrelevant.  The bottom line is that
> >> a DOS shell must be used and so my suggestion is:
> >>
> >> 1.  remove the if-block that defines the unix utilities and retain
> >> the else-block, and
> >>
> >> 2.  define SHELL=cmd.exe in the makefile.

If you write a patch for this, I will test it.


> Believe me, I fully understand that it's far-fetched that no one else
> has seen this problem before.  I can't explain that either! 

Maybe, most Windows developers here use MSVC mainly?

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: test_autocmd.vim missing from Make_all.mak

[Bram Moolenaar]

Yegappan Lakshmanan wrote:

> Why is the test_autocmd.vim file missing from src/testdir/Make_all.mak?
> When I added the test to Make_all.mak, I found the
> Test_cursorhold_insert() and Test_three_windows() tests are failing.

The test is loaded through testdir/test_alot.vim.

Strange that the tests pass when run through test_alot, but fail when
run directly.  Is it perhaps because test_autocmd.vim is the current
file?  Or some setting at a different value?

-- 
I'm so disorganized my keyboard isn't even in alphabetical order!

 /// 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: Test test_getcwd needs to have noswapfile option set

[Bram Moolenaar]

Michael Soyka wrote:

> The Vim test "test_getcwd" creates a temporary directory "Xtopdir" that 
> should be deleted at test conclusion but is not. This directory is not 
> deleted because the test has created swap files that apparently are open 
> when the test attempts to cleanup before terminating.
> 
> Setting the noswapfile option when the test begins, say by appending it 
> to line 10, fixes this problem.
> 
> I've noticed and fixed this problem under Windows 10.

I didn't notice it and I was specifically looking for files left behind
(git status shows them).  Perhaps there is a later test that does delete
the directory.  Anyway, I'll include your suggested fix.

-- 
If Microsoft would build a car...
... Occasionally your car would die on the freeway for no
reason. You would have to pull over to the side of the road,
close all of the car windows, shut it off, restart it, and
reopen the windows before you could continue. For some reason
you would simply accept this.

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

[Bram Moolenaar]

Patch 7.4.2334
Problem:On MS-Windows test_getcwd leaves Xtopdir behind.
Solution:   Set 'noswapfile'. (Michael Soyka)
Files:  src/testdir/test_getcwd.in


*** ../vim-7.4.2333/src/testdir/test_getcwd.in  2016-06-08 21:48:47.197167861 
+0200
--- src/testdir/test_getcwd.in  2016-09-05 23:24:17.547369398 +0200
***
*** 9,14 
--- 9,17 
  :set visualbell
  :set nocp viminfo+=nviminfo
  :"
+ :" On windows a swapfile in Xtopdir prevents it from being cleaned up.
+ :set noswapfile
+ :"
  :function! GetCwdInfo(win, tab)
  : let tab_changed = 0
  : let mod = ":t"
*** ../vim-7.4.2333/src/version.c   2016-09-05 22:58:28.317270558 +0200
--- src/version.c   2016-09-05 23:25:14.174872787 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2334,
  /**/


-- 
If Microsoft would build a car...
... The airbag system would ask "are you SURE?" before deploying.

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

[Bram Moolenaar]

Patch 7.4.2333
Problem:Outdated comments in test.
Solution:   Cleanup normal mode test. (Christian Brabandt)
Files:  src/testdir/test_normal.vim


*** ../vim-7.4.2332/src/testdir/test_normal.vim 2016-09-04 15:13:36.617508762 
+0200
--- src/testdir/test_normal.vim 2016-09-05 22:49:24.322418349 +0200
***
*** 36,82 
  endfunction
  
  fun! Test_normal00_optrans()
-   " Attention: This needs to be the very first test,
-   " it will fail, if it runs later, don't know why!
-   " Test for S s and alike comamnds, that are internally handled aliased
new
call append(0, ['1 This is a simple test: abcd', '2 This is the second 
line', '3 this is the third line'])
1
exe "norm! Sfoobar\"
call assert_equal(['foobar', '2 This is the second line', '3 this is the 
third line', ''], getline(1,'$'))
2
-   " Test does not work
-   " TODO: Why does it not work?
-   " Adds an additional linebreak if used in visual mode...
-   " When run in the test, this returns:
-   " ,
-   " |foobar
-   " |2 This is
-   " |the second
-   " |one
-   " |3 this is the third line
-   " `---
-   " instead of
-   " ,
-   " |foobar
-   " |2 This is the second one
-   " |3 this is the third line
-   " `---
exe "norm! $vbsone"
call assert_equal(['foobar', '2 This is the second one', '3 this is the 
third line', ''], getline(1,'$'))
-   " When run in the test, this returns:
-   " ,
-   " |foobar
-   " |Second line
-   " |here
-   " |3 this is the third line
-   " `---
-   " instead of
-   " ,
-   " |foobar
-   " |Second line here
-   " |3 this is the third line
-   " `---
norm! VS Second line here
call assert_equal(['foobar', ' Second line here', '3 this is the third 
line', ''], getline(1, '$'))
%d
--- 36,49 
***
*** 248,254 
norm! gggqG
call assert_equal(['123', '456', '789', '1011   
 '], getline(1, '$'))
" clean up
!   set formatprg=
bw!
  endfu
  
--- 215,221 
norm! gggqG
call assert_equal(['123', '456', '789', '1011   
 '], getline(1, '$'))
" clean up
!   set formatprg= tw=0
bw!
  endfu
  
***
*** 1719,1725 
" Test for g<
" Cannot capture its output,
" probably a bug, therefore, test disabled:
!   return
echo "a\nb\nc\nd"
let b=execute(':norm! g<')
call assert_true(!empty(b), 'failed `execute(g<)`')
--- 1686,1692 
" Test for g<
" Cannot capture its output,
" probably a bug, therefore, test disabled:
!   throw "Skipped: output of g< can't be tested currently"
echo "a\nb\nc\nd"
let b=execute(':norm! g<')
call assert_true(!empty(b), 'failed `execute(g<)`')
***
*** 1877,1883 
  
" clean up
set sts=0 sw=8 ts=8
!   "bw!
  endfu
  
  func! Test_normal42_halfpage()
--- 1844,1850 
  
" clean up
set sts=0 sw=8 ts=8
!   bw!
  endfu
  
  func! Test_normal42_halfpage()
*** ../vim-7.4.2332/src/version.c   2016-09-05 22:45:25.072731086 +0200
--- src/version.c   2016-09-05 22:53:44.931920248 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2333,
  /**/


-- 
If Apple would build a car...
... it would be powered by the sun, be reliable, five times
as fast and twice as easy to drive; but would only run on
five percent of the roads.

 /// 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: small adjustments to test_normal.vim

[Bram Moolenaar]

Christian Brabandt wrote:

> Hi,
> this patch adds some small changes to the test_normal.vim test
> 
> - throw "Skipped" for the skipped part of the test (since that is now 
>   possible since 7.4.2321)
> - fixes some small bugs
> - removes obsolete comments
> 
> I will probably go through coverity and add some more tests within the 
> next time, but don't expect more tests soon.

Thanks.

-- 
If Microsoft would build a car...
... the oil, water temperature, and alternator warning lights would
all be replaced by a single "General Protection Fault" warning light.

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

[Bram Moolenaar]

Ozaki Kiichi wrote:

> Calling timer_stop in timer-callback causes SEGV.
> 
> [repro steps]
> 
> test.vim:
> 
> function! StopTimer1(timer)
>   let g:timer2 = timer_start(50, 'StopTimer2')
>   " avoid bothersome maxfuncdepth error
>   call timer_pause(g:timer1, 1)
>   sleep 100m
> endfunction
> 
> function! StopTimer2(timer)
>   let g:timer3 = timer_start(50, 'StopTimer3')
>   call timer_stop(g:timer1)
> endfunction
> 
> function! StopTimer3(timer)
>   " Do nothing
> endfunction
> 
> function! TimerStart()
>   let g:timer1 = timer_start(50, 'StopTimer1')
>   sleep 100m
> endfunction
> 
> 
> vim -Nu NONE -S test.vim
> 
> :call TimerStart()
> 
> then vim aborts.
> 
> [other problem]
> 
> Vim hangs up when timer is firing frequently.
> 
> test.vim:
> 
> function! TimerStart()
>   call timer_start(0, 'TimerCallback', {'repeat' : -1})
> endfunction
> function! TimerCallback(...)
> endfunction
> 
> 
> vim -Nu NONE -S test.vim
> 
> :call TimerStart()
> 
> then vim hangs up and we can't intercept by Ctrl-C.
> 
> [patch]
> 
> https://gist.github.com/ichizok/d6637a6d368bbf1353a35441c34039a7
> 
> * evalfunc.c patch is not concerned with those problems, this modifies 
> efficiency of timer_start() slightly.

Thanks, nice solution.

-- 
hundred-and-one symptoms of being an internet addict:
173. You keep tracking down the email addresses of all your friends
 (even childhood friends).

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

[Bram Moolenaar]

Patch 7.4.2332
Problem:Crash when stop_timer() is called in a callback of a callback.
Vim hangs when the timer callback uses too much time.
Solution:   Set tr_id to -1 when a timer is to be deleted. Don't keep calling
callbacks forever. (Ozaki Kiichi)
Files:  src/evalfunc.c, src/ex_cmds2.c, src/structs.h,
src/proto/ex_cmds2.pro, src/testdir/test_timers.vim


*** ../vim-7.4.2331/src/evalfunc.c  2016-09-04 21:42:32.410056052 +0200
--- src/evalfunc.c  2016-09-05 22:32:11.684576179 +0200
***
*** 12398,12409 
  static void
  f_timer_start(typval_T *argvars, typval_T *rettv)
  {
! longmsec = (long)get_tv_number([0]);
! timer_T *timer;
! int   repeat = 0;
! char_u  *callback;
! dict_T  *dict;
  
  if (check_secure())
return;
  if (argvars[2].v_type != VAR_UNKNOWN)
--- 12398,12411 
  static void
  f_timer_start(typval_T *argvars, typval_T *rettv)
  {
! long  msec = (long)get_tv_number([0]);
! timer_T   *timer;
! int   repeat = 0;
! char_u*callback;
! dict_T*dict;
! partial_T *partial;
  
+ rettv->vval.v_number = -1;
  if (check_secure())
return;
  if (argvars[2].v_type != VAR_UNKNOWN)
***
*** 12418,12430 
repeat = get_dict_number(dict, (char_u *)"repeat");
  }
  
! timer = create_timer(msec, repeat);
! callback = get_callback([1], >tr_partial);
  if (callback == NULL)
! {
!   stop_timer(timer);
!   rettv->vval.v_number = -1;
! }
  else
  {
if (timer->tr_partial == NULL)
--- 12420,12432 
repeat = get_dict_number(dict, (char_u *)"repeat");
  }
  
! callback = get_callback([1], );
  if (callback == NULL)
!   return;
! 
! timer = create_timer(msec, repeat);
! if (timer == NULL)
!   free_callback(callback, partial);
  else
  {
if (timer->tr_partial == NULL)
***
*** 12432,12438 
else
/* pointer into the partial */
timer->tr_callback = callback;
!   rettv->vval.v_number = timer->tr_id;
  }
  }
  
--- 12434,12441 
else
/* pointer into the partial */
timer->tr_callback = callback;
!   timer->tr_partial = partial;
!   rettv->vval.v_number = (varnumber_T)timer->tr_id;
  }
  }
  
*** ../vim-7.4.2331/src/ex_cmds2.c  2016-09-02 22:18:45.458101130 +0200
--- src/ex_cmds2.c  2016-09-05 22:33:24.691896430 +0200
***
*** 1088,1097 
  
  # if defined(FEAT_TIMERS) || defined(PROTO)
  static timer_T*first_timer = NULL;
! static intlast_timer_id = 0;
  
! static timer_T*current_timer = NULL;
! static intfree_current_timer = FALSE;
  
  /*
   * Insert a timer in the list of timers.
--- 1088,1104 
  
  # if defined(FEAT_TIMERS) || defined(PROTO)
  static timer_T*first_timer = NULL;
! static long   last_timer_id = 0;
  
! # ifdef WIN3264
! #  define GET_TIMEDIFF(timer, now) \
!   (long)(((double)(timer->tr_due.QuadPart - now.QuadPart) \
!  / (double)fr.QuadPart) * 1000);
! # else
! #  define GET_TIMEDIFF(timer, now) \
!   (timer->tr_due.tv_sec - now.tv_sec) * 1000 \
!  + (timer->tr_due.tv_usec - now.tv_usec) / 1000;
! # endif
  
  /*
   * Insert a timer in the list of timers.
***
*** 1124,1136 
  static void
  free_timer(timer_T *timer)
  {
! if (timer == current_timer)
!   free_current_timer = TRUE;
! else
! {
!   free_callback(timer->tr_callback, timer->tr_partial);
!   vim_free(timer);
! }
  }
  
  /*
--- 1131,1138 
  static void
  free_timer(timer_T *timer)
  {
! free_callback(timer->tr_callback, timer->tr_partial);
! vim_free(timer);
  }
  
  /*
***
*** 1144,1150 
  
  if (timer == NULL)
return NULL;
! timer->tr_id = ++last_timer_id;
  insert_timer(timer);
  if (repeat != 0)
timer->tr_repeat = repeat - 1;
--- 1146,1155 
  
  if (timer == NULL)
return NULL;
! if (++last_timer_id < 0)
!   /* Overflow!  Might cause duplicates... */
!   last_timer_id = 0;
! timer->tr_id = last_timer_id;
  insert_timer(timer);
  if (repeat != 0)
timer->tr_repeat = repeat - 1;
***
*** 1165,1171 
  typval_T  argv[2];
  
  argv[0].v_type = VAR_NUMBER;
! argv[0].vval.v_number = timer->tr_id;
  argv[1].v_type = VAR_UNKNOWN;
  
  call_func(timer->tr_callback, (int)STRLEN(timer->tr_callback),
--- 1170,1176 
  typval_T  argv[2];
  
  argv[0].v_type = VAR_NUMBER;
! argv[0].vval.v_number = (varnumber_T)timer->tr_id;
  argv[1].v_type = VAR_UNKNOWN;
  
  call_func(timer->tr_callback, (int)STRLEN(timer->tr_callback),
***
*** 1182,1258 
  check_due_timer(void)
  {
  timer_T   

test_autocmd.vim missing from Make_all.mak

[Yegappan Lakshmanan]

Hi all,

Why is the test_autocmd.vim file missing from src/testdir/Make_all.mak?
When I added the test to Make_all.mak, I found the
Test_cursorhold_insert() and Test_three_windows() tests are failing.

- Yegappan

-- 
-- 
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] read heap overflow in do_pending_operator()

[Dominique Pellé]

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 (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7787== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==7787== Command: vim -u NONE -S bug.vim -c q
==7787==
==7787== Invalid read of size 1
==7787==at 0x4D881C: do_pending_operator (normal.c:1700)
==7787==by 0x4E39F8: clip_get_selection (ops.c:6428)
==7787==by 0x59F800: clip_copy_selection (ui.c:544)
==7787==by 0x59F7A3: clip_auto_select (ui.c:614)
==7787==by 0x4D7E06: end_visual_mode (normal.c:3281)
==7787==by 0x465A6E: ex_operators (ex_docmd.c:9243)
==7787==by 0x45EC77: do_one_cmd (ex_docmd.c:2962)
==7787==by 0x45A9F2: do_cmdline (ex_docmd.c:1110)
==7787==by 0x458ADC: do_source (ex_cmds2.c:4097)
==7787==by 0x4582D3: cmd_source (ex_cmds2.c:3710)
==7787==by 0x45EC77: do_one_cmd (ex_docmd.c:2962)
==7787==by 0x45A9F2: do_cmdline (ex_docmd.c:1110)
==7787==by 0x5CEEEC: exe_commands (main.c:2896)
==7787==by 0x5CEEEC: vim_main2 (main.c:781)
==7787==by 0x5CD91C: main (main.c:415)
==7787==  Address 0x76b0b80 is 0 bytes after a block of size 4,096 alloc'd
==7787==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
==7787==by 0x4C81D7: lalloc (misc2.c:942)
==7787==by 0x5D127E: mf_alloc_bhdr (memfile.c:907)
==7787==by 0x5D127E: mf_new (memfile.c:381)
==7787==by 0x4AC6F1: ml_new_data (memline.c:3513)
==7787==by 0x4AC6F1: ml_open (memline.c:400)
==7787==by 0x406373: open_buffer (buffer.c:160)
==7787==by 0x5CEA44: create_windows (main.c:2668)
==7787==by 0x5CEA44: vim_main2 (main.c:704)
==7787==by 0x5CD91C: main (main.c:415)

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.


bug.vim
Description: Binary data

Patch 7.4.2331

[Bram Moolenaar]

Patch 7.4.2331
Problem:Using CTRL-X CTRL-V to complete a command line from Insert mode
does not work after entering an expression on the command line.
Solution:   Don't use "ccline" when not actually using a command line. (test
by Hirohito Higashi)
Files:  src/edit.c, src/ex_getln.c, src/proto/ex_getln.pro,
src/testdir/test_popup.vim


*** ../vim-7.4.2330/src/edit.c  2016-08-29 22:48:12.121106421 +0200
--- src/edit.c  2016-09-05 20:53:05.025082101 +0200
***
*** 5304,5310 
if (compl_pattern == NULL)
return FAIL;
set_cmd_context(_xp, compl_pattern,
!(int)STRLEN(compl_pattern), curs_col);
if (compl_xp.xp_context == EXPAND_UNSUCCESSFUL
|| compl_xp.xp_context == EXPAND_NOTHING)
/* No completion possible, use an empty pattern to get a
--- 5304,5310 
if (compl_pattern == NULL)
return FAIL;
set_cmd_context(_xp, compl_pattern,
! (int)STRLEN(compl_pattern), curs_col, FALSE);
if (compl_xp.xp_context == EXPAND_UNSUCCESSFUL
|| compl_xp.xp_context == EXPAND_NOTHING)
/* No completion possible, use an empty pattern to get a
*** ../vim-7.4.2330/src/ex_getln.c  2016-09-03 21:04:54.989247387 +0200
--- src/ex_getln.c  2016-09-05 20:56:00.343600510 +0200
***
*** 4509,4515 
xp->xp_context = EXPAND_NOTHING;
return;
  }
! set_cmd_context(xp, ccline.cmdbuff, ccline.cmdlen, ccline.cmdpos);
  }
  
  void
--- 4509,4515 
xp->xp_context = EXPAND_NOTHING;
return;
  }
! set_cmd_context(xp, ccline.cmdbuff, ccline.cmdlen, ccline.cmdpos, TRUE);
  }
  
  void
***
*** 4517,4523 
  expand_T  *xp,
  char_u*str,   /* start of command line */
  int   len,/* length of command line (excl. NUL) */
! int   col)/* position of cursor */
  {
  int   old_char = NUL;
  char_u*nextcomm;
--- 4517,4524 
  expand_T  *xp,
  char_u*str,   /* start of command line */
  int   len,/* length of command line (excl. NUL) */
! int   col,/* position of cursor */
! int   use_ccline UNUSED) /* use ccline for info */
  {
  int   old_char = NUL;
  char_u*nextcomm;
***
*** 4532,4545 
  nextcomm = str;
  
  #ifdef FEAT_EVAL
! if (ccline.cmdfirstc == '=')
  {
  # ifdef FEAT_CMDL_COMPL
/* pass CMD_SIZE because there is no real command */
set_context_for_expression(xp, str, CMD_SIZE);
  # endif
  }
! else if (ccline.input_fn)
  {
xp->xp_context = ccline.xp_context;
xp->xp_pattern = ccline.cmdbuff;
--- 4533,4546 
  nextcomm = str;
  
  #ifdef FEAT_EVAL
! if (use_ccline && ccline.cmdfirstc == '=')
  {
  # ifdef FEAT_CMDL_COMPL
/* pass CMD_SIZE because there is no real command */
set_context_for_expression(xp, str, CMD_SIZE);
  # endif
  }
! else if (use_ccline && ccline.input_fn)
  {
xp->xp_context = ccline.xp_context;
xp->xp_pattern = ccline.cmdbuff;
*** ../vim-7.4.2330/src/proto/ex_getln.pro  2016-09-03 16:29:01.450841139 
+0200
--- src/proto/ex_getln.pro  2016-09-05 20:54:23.392419815 +0200
***
*** 30,36 
  void tilde_replace(char_u *orig_pat, int num_files, char_u **files);
  char_u *sm_gettail(char_u *s);
  char_u *addstar(char_u *fname, int len, int context);
! void set_cmd_context(expand_T *xp, char_u *str, int len, int col);
  int expand_cmdline(expand_T *xp, char_u *str, int col, int *matchcount, 
char_u ***matches);
  int ExpandGeneric(expand_T *xp, regmatch_T *regmatch, int *num_file, char_u 
***file, char_u *((*func)(expand_T *, int)), int escaped);
  void globpath(char_u *path, char_u *file, garray_T *ga, int expand_options);
--- 30,36 
  void tilde_replace(char_u *orig_pat, int num_files, char_u **files);
  char_u *sm_gettail(char_u *s);
  char_u *addstar(char_u *fname, int len, int context);
! void set_cmd_context(expand_T *xp, char_u *str, int len, int col, int 
use_ccline);
  int expand_cmdline(expand_T *xp, char_u *str, int col, int *matchcount, 
char_u ***matches);
  int ExpandGeneric(expand_T *xp, regmatch_T *regmatch, int *num_file, char_u 
***file, char_u *((*func)(expand_T *, int)), int escaped);
  void globpath(char_u *path, char_u *file, garray_T *ga, int expand_options);
*** ../vim-7.4.2330/src/testdir/test_popup.vim  2016-09-03 22:35:02.396409822 
+0200
--- src/testdir/test_popup.vim  2016-09-05 20:52:36.909316640 +0200
***
*** 242,263 
iunmap 
  endfunc
  
- function! ComplTest() abort
-   call complete(1, ['source', 'soundfold'])
-   return ''
- endfunction
- 
  func 

Re: callback is not called when job exit immediately.

[Bram Moolenaar]

Yasuhiro Matsumoto wrote:

> behavior is I expected. but tests are failing with my patch.
> 
> From test_channel.vim:
> Found errors in Test_out_close_cb():
> function RunTheTest[9]..Test_out_close_cb line 26: Expected 2 but got 0
> Found errors in Test_pipe_to_buffer_name():
> function RunTheTest[9]..Test_pipe_to_buffer_name[1]..Run_test_pipe_to_buffer 
> line 35: Expected 'yes' but got 'no'
> Found errors in Test_pipe_to_buffer_name_nomod():
> Caught exception in Test_pipe_to_buffer_name_nomod(): Vim(sleep):E117: 
> Unknown function: CloseHandler @ function 
> RunTheTest[9]..Test_pipe_to_buffer_name_nomod[1]..Run_test_pipe_to_buffer[28]..WaitFor,
>  line 20
> Found errors in Test_read_in_close_cb():
> function RunTheTest[9]..Test_read_in_close_cb line 15: Expected 'quit' but 
> got ''

Maybe PeekNamedPipe() is not the right function to use?
How about doing a non-blocking read?

-- 
In Joseph Heller's novel "Catch-22", the main character tries to get out of a
war by proving he is crazy.  But the mere fact he wants to get out of the war
only shows he isn't crazy -- creating the original "Catch-22".

 /// 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] corrections in runtime/doc/version8.txt

[Bram Moolenaar]

Marius Gedminas wrote:

> On Sat, Sep 03, 2016 at 06:43:06AM +0200, Dominique Pellé wrote:
> > 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),
> 
> I don't think you want to close the parenthesis here
> 
> >  closes #507)
> >  Files:  src/Makefile, src/auto/configure, src/config.h.in,
> >  src/config.mk.in, src/configure.in, src/gui_gtk.c,

Thanks.

-- 
Living in Hollywood is like living in a bowl of granola.  What ain't
fruits and nuts is flakes.

 /// 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] corrections in runtime/doc/version8.txt

[Bram Moolenaar]

Ken Takata wrote:

> I also found some typos in the documents.

Thanks.


-- 
hundred-and-one symptoms of being an internet addict:
171. You invent another person and chat with yourself in empty chat rooms.

 /// 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: callback is not called when job exit immediately.

[Bram Moolenaar]

Yasuhiro Matsumoto wrote:

> On Monday, September 5, 2016 at 11:30:42 AM UTC+9, mattn wrote:
> > > Isn't the best solution then to have channel_wait() not return an error?
> > > Or is there some way to detect the situation, perhaps by using
> > > LastError().  At least it should only affect Windows, since on Unix we
> > > don't want to make this exception.
> > 
> > I say again, This is posssible to be reproduced on Linux.
> 
> While the process alive, stdout is not filled in the buffer. But when
> the process exited, buffer should be flushed. So if we change this
> like below to debug output,
> 
> ---
> diff --git a/src/channel.c b/src/channel.c
> index 10ed42e..15a3f72 100644
> --- a/src/channel.c
> +++ b/src/channel.c
> @@ -59,6 +59,12 @@ static void channel_read(channel_T *channel, int part, 
> char *func);
>  /* Whether a redraw is needed for appending a line to a buffer. */
>  static int channel_need_redraw = FALSE;
>  
> +static void debuglog(char* buf) {
> +  FILE *fp = fopen("debug.log", "a");
> +  fprintf(fp, "%s\n", buf);
> +  fclose(fp);
> +}
> +
>  /* Whether we are inside channel_parse_messages() or another situation where 
> it
>   * is safe to invoke callbacks. */
>  static int safe_to_invoke_callback = 0;
> @@ -2894,11 +2900,14 @@ channel_wait(channel_T *channel, sock_T fd, int 
> timeout)
>   while (TRUE)
>   {
>   int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, , NULL);
> + char buff[256];
> + sprintf(buff, "polling %ld, %d, %ld", nread, r, GetLastError());
> + debuglog(buff);
>  
> - if (r && nread > 0)
> - return CW_READY;
>   if (r == 0)
>   return CW_ERROR;
> + if (nread > 0)
> + return CW_READY;
>  
>   /* perhaps write some buffer lines */
>   channel_write_any_lines();
> @@ -3003,6 +3012,7 @@ channel_close_on_error(channel_T *channel, char *func)
>   * died.  Don't close the channel right away, it may be the wrong moment
>   * to invoke callbacks. */
>  channel->ch_to_be_closed = TRUE;
> +debuglog("close");
>  
>  #ifdef FEAT_GUI
>  /* Stop listening to GUI events right away. */
> @@ -3033,9 +3043,6 @@ channel_read(channel_T *channel, int part, char *func)
>  sock_T   fd;
>  int  use_socket = FALSE;
>  
> -/* If we detected a read error don't try reading again. */
> -if (channel->ch_to_be_closed)
> - return;
>  
>  fd = channel->ch_part[part].ch_fd;
>  if (fd == INVALID_FD)
> @@ -3045,6 +3052,14 @@ channel_read(channel_T *channel, int part, char *func)
>  }
>  use_socket = fd == channel->CH_SOCK_FD;
>  
> +{
> +  DWORD nread;
> +  int r = PeekNamedPipe((HANDLE)fd, NULL, 0, NULL, , NULL);
> +  char buff[256];
> +  sprintf(buff, "let's read %ld, %d", nread, r);
> +  debuglog(buff);
> +}
> +
>  /* Allocate a buffer to read into. */
>  if (buf == NULL)
>  {
> ---
> 
> The output become:
> 
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 1, 0
> polling 0, 0, 109
> close
> polling 18, 1, 0
> let's read 18, 1
> polling 18, 1, 0
> 
> Then, I check GetLastError() to ignore ERROR_BROKEN_BUFFER that occur
> when process exited.

Surprising to see that first it returns an error and then later shows
bytes are available to readl.  So ignoring code 109 (I believe that's
ERROR_BROKEN_PIPE) seems appropriate.

-- 
hundred-and-one symptoms of being an internet addict:
170. You introduce your wife as "my_l...@home.wife" and refer to your
 children as "forked processes."

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

[Bram Moolenaar]

Hirohito Higashi wrote:

> Hi Bram and developers!
> 
> 2016-9-4(Sun) 22:40:41 UTC+9 h_east:
> > Hi Bram and developers,
> > 
> > 2016-9-3(Sat) 21:52:42 UTC+9 Bram Moolenaar:
> > > Hirohito Higashi wrote:
> > > 
> > > > 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.
> > > 
> > > Isn't the problem that the completion is using ccline, but when getting
> > > there from insert mode it's never set?  So ccline.cmdfirstc is "="
> > > because of the previous command.
> > 
> > Okay. I would try to more investigate.
> > Thanks.
> 
> I had more investigate and update a patch.
> Perhaps, you will accept an attached patch :-)

Hmm, this still has some unexpected dependency.  How about this: when
set_cmd_context() is called from ins_complete() pass a flag that means
"do not using ccline".  Then in set_cmd_context() skip the part that uses
ccline.  Oh well, I suppose I might as well do that then.  And use your
test, that's the bulk of the work.


-- 
Did you ever see a "Hit any key to continue" message in a music piece?

 /// 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: callback is not called when job exit immediately.

[Bram Moolenaar]

Yasuhiro Matsumoto wrote:

> > Isn't the best solution then to have channel_wait() not return an error?
> > Or is there some way to detect the situation, perhaps by using
> > LastError().  At least it should only affect Windows, since on Unix we
> > don't want to make this exception.
> 
> I say again, This is posssible to be reproduced on Linux.

How?  Perhaps by inserting a delay somewhere?

We could do something like "read once after the pipe was closed" but
without being able to reproduce it I won't know if it actually works.

-- 
hundred-and-one symptoms of being an internet addict:
169. You hire a housekeeper for your home page.

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

[h_east]

Hi Bram and developers!

2016-9-4(Sun) 22:40:41 UTC+9 h_east:
> Hi Bram and developers,
> 
> 2016-9-3(Sat) 21:52:42 UTC+9 Bram Moolenaar:
> > Hirohito Higashi wrote:
> > 
> > > 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.
> > 
> > Isn't the problem that the completion is using ccline, but when getting
> > there from insert mode it's never set?  So ccline.cmdfirstc is "="
> > because of the previous command.
> 
> Okay. I would try to more investigate.
> Thanks.

I had more investigate and update a patch.
Perhaps, you will accept 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 ed82f0f..5f1e386 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -218,6 +218,7 @@ getcmdline(
  * custom status line may invoke ":normal". */
 struct cmdline_info save_ccline;
 #endif
+int		cmdfirstc_save;
 
 #ifdef FEAT_EVAL
 if (firstc == -1)
@@ -249,13 +250,19 @@ getcmdline(
 /*
  * set some variables for redrawcmd()
  */
+if (firstc == '=')
+	cmdfirstc_save = ccline.cmdfirstc;
 ccline.cmdfirstc = (firstc == '@' ? 0 : firstc);
 ccline.cmdindent = (firstc > 0 ? indent : 0);
 
 /* alloc initial ccline.cmdbuff */
 alloc_cmdbuff(exmode_active ? 250 : indent + 1);
 if (ccline.cmdbuff == NULL)
+{
+	if (firstc == '=')
+	ccline.cmdfirstc = cmdfirstc_save;
 	return NULL;			/* out of memory */
+}
 ccline.cmdlen = ccline.cmdpos = 0;
 ccline.cmdbuff[0] = NUL;
 
@@ -2085,6 +2092,8 @@ returncmd:
 
 	/* Make ccline empty, getcmdline() may try to use it. */
 	ccline.cmdbuff = NULL;
+	if (firstc == '=')
+	ccline.cmdfirstc = cmdfirstc_save;
 	return p;
 }
 }
diff --git a/src/testdir/test_autocmd.vim b/src/testdir/test_autocmd.vim
index c029ca1..264cad8 100644
--- a/src/testdir/test_autocmd.vim
+++ b/src/testdir/test_autocmd.vim
@@ -220,6 +220,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 dd94933..6e07393 100644
--- a/src/testdir/test_popup.vim
+++ b/src/testdir/test_popup.vim
@@ -242,22 +242,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!
@@ -266,10 +271,20 @@ func Test_noinsert_complete()
   iunmap 
 endfunc
 
+func Test_compl_vim_cmds_after_register_expr()
+  function! s:test_func()
+return 'autocmd '
+  endfunction
+  augroup A_Group
+au!
+  augroup END
 
-function! Test() abort
-  call complete(1, ['source', 'soundfold'])
-  return ''
-endfunction
+  new
+  call feedkeys("i\=s:test_func()", 'tx')
+  call assert_equal('autocmd A_Group', getline(1))
+  autocmd! A_Group
+  augroup! A_Group
+  bwipe!
+endfunc
 
 " vim: shiftwidth=2 sts=2 expandtab

Re: Patch 7.4.2304

[Ozaki Kiichi]

[complement]

> then vim hangs up and we can't intercept by Ctrl-C.

Sorry, 'hang up' is incorrect. Vim accepts key input and redraws screen,
but we can't leave from normal mode.

> https://gist.github.com/ichizok/d6637a6d368bbf1353a35441c34039a7

This patch changes:

* add 'tr_firing' variable to timer_S, this indicates timer-callback firing 
state.

* last_timer_id is non-negative value. tr_id == -1 means deleted timer.

* in check_due_timer(), remove while loop in order to fix above problem.

* stop_timer() sets tr_id to -1 when tr_firing is TRUE, and timer is actually 
deleted after its callback has finished.

-- 
-- 
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: callback is not called when job exit immediately.

[mattn]

On Tuesday, September 6, 2016 at 12:01:35 AM UTC+9, mattn wrote:
> Below's change fixes this issue, and not break tests.
> 
> https://gist.github.com/214b61186e2fe091fa65e2b6fbaa8069
> 
> Thanks.

Ah, sorry noisy. Still wrong...

-- 
-- 
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: callback is not called when job exit immediately.

[mattn]

Below's change fixes this issue, and not break tests.

https://gist.github.com/214b61186e2fe091fa65e2b6fbaa8069

Thanks.

-- 
-- 
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: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10

[Michael Soyka]

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 command.com or cmd.exe

My version of make, gnu 3.82.90, sets the SHELL make variable to the
value "C:/MinGW/msys/1.0/sh.exe", a unix shell, and so all such
if-statements fail.

This can be sidestepped by setting SHELL=cmd.exe on the make command
line but then unix utilities such as "rm" are used instead of "del" and
DIRSLASH is set to "/" instead of "\" and so vim.exe cannot be launched
to run the test (cmd.exe does not accept forward slashes in paths).
This new problem is caused by an incorrectly constructed if-test in the
makefile:

ifneq(sh.exe,$(SHELL))

followed by unix-style definitions.  I think that the author had
intended this

ifeq(sh.exe, $(SHELL))

No, this is confusing but intended. Please try the following Makefile:

   all:
echo $(SHELL)

If you run mingw32-make.exe (not make.exe) on cmd.exe, you will see the
following result:

   C:\tmp>\msys32\mingw32\bin\mingw32-make.exe
   echo sh.exe
   sh.exe

No, this is not what I see.  I see "C:/MinGW/msys/1.0/sh.exe"


Other results are...

make.exe on cmd.exe:

   C:\tmp>\msys32\usr\bin\make.exe
   echo /bin/sh
   make: echo: Command not found
   make: *** [Makefile.mingw:2: all] Error 127

This doesn't work as expected.

mingw32-make.exe on bash.exe:

   $ mingw32-make
   echo C:/msys32/usr/bin/sh.exe
   C:/msys32/usr/bin/sh.exe

make.exe on bash.exe:

   $ make
   echo /bin/sh
   /bin/sh


Normally, mingw32-make should be used when the shell is cmd.exe.
(I don't know when the shell is bash.exe.)


My apologies for not being clearer.  I am running mingw32-make.  I did 
exactly what you suggested above and got "C:/MinGW/msys/1.0/sh.exe" for 
SHELL. In the interest of full disclosure, I'm using TDM-GCC-64 to build 
Vim and run the tests. It does not include a unix shell.  Its version of 
make apparently looks for and finds one in my MinGW/msys installation 
which is on my path.


Given all your examples above, if the makefile must include unix shell support, 
wouldn't the better implementation have been:
  ifeq("cmd.exe", $(SHELL))
followed by the DOS definitions?  This covers SHELL being "sh", "/bin/sh" or 
whatever.  That said, I still claim that
  ifeq("cmd.exe", $(notdir $(SHELL)))
is the right thing to do in case the value of SHELL includes a path.

Again, I see this discussion if ifneq/ifeq statements as somewhat irrelevant since the 
"if exist" statements in the makefile assume/demand a cmd shell.





but this won't work either because the value of SHELL will include a
full path, if make is allowed to define it.

The correct construct is this:

ifeq(sh.exe, $(notdir $(SHELL)))

which strips the path information from SHELL before the comparison.

This is all interesting but mostly irrelevant.  The bottom line is that
a DOS shell must be used and so my suggestion is:

1.  remove the if-block that defines the unix utilities and retain
the else-block, and

2.  define SHELL=cmd.exe in the makefile.

I haven't tried this yet.
Does this work both on cmd.exe and bash.exe?

Regards,
Ken Takata


I build Vim and run the tests in a cmd.exe shell. My experience is that 
the two suggestions I make above make it possible for me to run all the 
tests without error.  If I don't go out of my way to specify SHELL 
somehow, either in the makefile or on the command line, mingw32-make 
generates errors when it tries to execute the "if exist" statements.


Believe me, I fully understand that it's far-fetched that no one else 
has seen this problem before.  I can't explain that either!


-mike

--
--
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] corrections in runtime/doc/version8.txt

[Ken Takata]

Hi,

I also found some typos in the documents.

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.
# HG changeset patch
# Parent  e205ed63ebb600e99d488739e4d3c9cd2c61cfd0

diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -119,7 +119,7 @@ To test for a non-empty string, use empt
 			*non-zero-arg*
 Function arguments often behave slightly different from |TRUE|: If the
 argument is present and it evaluates to a non-zero Number, |v:true| or a
-non-empty String, then the value is considere to be TRUE.
+non-empty String, then the value is considered to be TRUE.
 Note that " " and "0" are also non-empty strings, thus cause the mode to be
 cleared.  A List, Dictionary or Float is not a Number or String, thus
 evaluates to FALSE.
diff --git a/runtime/doc/version8.txt b/runtime/doc/version8.txt
--- a/runtime/doc/version8.txt
+++ b/runtime/doc/version8.txt
@@ -13020,7 +13020,7 @@ Files:  src/evalfunc.c, src/version.
 
 Patch 7.4.2122 (after 7.4.2118)
 Problem:Mac: don't get +clipboard in huge build.
-Solution:   Move #define down below including featureh.h
+Solution:   Move #define down below including feature.h
 Files:  src/vim.h
 
 Patch 7.4.2123
@@ -13145,7 +13145,7 @@ Files:  src/userfunc.c, src/proto/us
 src/testdir/test_lambda.vim
 
 Patch 7.4.2144
-Problem:On MS-Windows quickix does not handle a line with 1023 bytes
+Problem:On MS-Windows quickfix does not handle a line with 1023 bytes
 ending in CR-LF properly.
 Solution:   Don't consider CR a line break. (Ken Takata)
 Files:  src/quickfix.c

small adjustments to test_normal.vim

[Christian Brabandt]

Hi,
this patch adds some small changes to the test_normal.vim test

- throw "Skipped" for the skipped part of the test (since that is now 
  possible since 7.4.2321)
- fixes some small bugs
- removes obsolete comments

I will probably go through coverity and add some more tests within the 
next time, but don't expect more tests soon.

Best,
Christian

-- 
-- 
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 0c97a7b05f36c0557fbed1e2f029dca998f9c489 Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Mon, 5 Sep 2016 00:13:24 +0200
Subject: [PATCH] Small adjustments to test_normal.vim

---
 src/testdir/test_normal.vim | 39 +++
 1 file changed, 3 insertions(+), 36 deletions(-)

diff --git a/src/testdir/test_normal.vim b/src/testdir/test_normal.vim
index 34561ff..9a8f8f8 100644
--- a/src/testdir/test_normal.vim
+++ b/src/testdir/test_normal.vim
@@ -36,47 +36,14 @@ function! CountSpaces(type, ...)
 endfunction
 
 fun! Test_normal00_optrans()
-  " Attention: This needs to be the very first test,
-  " it will fail, if it runs later, don't know why!
-  " Test for S s and alike comamnds, that are internally handled aliased
   new
   call append(0, ['1 This is a simple test: abcd', '2 This is the second line', '3 this is the third line'])
   1
   exe "norm! Sfoobar\"
   call assert_equal(['foobar', '2 This is the second line', '3 this is the third line', ''], getline(1,'$'))
   2
-  " Test does not work
-  " TODO: Why does it not work?
-  " Adds an additional linebreak if used in visual mode...
-  " When run in the test, this returns:
-  " ,
-  " |foobar
-  " |2 This is
-  " |the second
-  " |one
-  " |3 this is the third line
-  " `---
-  " instead of
-  " ,
-  " |foobar
-  " |2 This is the second one
-  " |3 this is the third line
-  " `---
   exe "norm! $vbsone"
   call assert_equal(['foobar', '2 This is the second one', '3 this is the third line', ''], getline(1,'$'))
-  " When run in the test, this returns:
-  " ,
-  " |foobar
-  " |Second line
-  " |here
-  " |3 this is the third line
-  " `---
-  " instead of
-  " ,
-  " |foobar
-  " |Second line here
-  " |3 this is the third line
-  " `---
   norm! VS Second line here
   call assert_equal(['foobar', ' Second line here', '3 this is the third line', ''], getline(1, '$'))
   %d
@@ -248,7 +215,7 @@ func! Test_normal07_internalfmt()
   norm! gggqG
   call assert_equal(['123', '456', '789', '1011'], getline(1, '$'))
   " clean up
-  set formatprg=
+  set formatprg= tw=0
   bw!
 endfu
 
@@ -1719,7 +1686,7 @@ fun! Test_normal35_g_cmd4()
   " Test for g<
   " Cannot capture its output,
   " probably a bug, therefore, test disabled:
-  return
+  throw "Skipped: output of g< can't be tested currently"
   echo "a\nb\nc\nd"
   let b=execute(':norm! g<')
   call assert_true(!empty(b), 'failed `execute(g<)`')
@@ -1877,7 +1844,7 @@ fun! Test_normal41_insert_reg()
 
   " clean up
   set sts=0 sw=8 ts=8
-  "bw!
+  bw!
 endfu
 
 func! Test_normal42_halfpage()
-- 
2.1.4

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

[Marius Gedminas]

On Sat, Sep 03, 2016 at 06:43:06AM +0200, Dominique Pellé wrote:
> 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),

I don't think you want to close the parenthesis here

>  closes #507)
>  Files:  src/Makefile, src/auto/configure, src/config.h.in,
>  src/config.mk.in, src/configure.in, src/gui_gtk.c,

Marius Gedminas
-- 
There are 10 kinds of people in the world: Those who understand binary
mathematics and those who don't.

-- 
-- 
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: PGP signature

Re: callback is not called when job exit immediately.

[mattn]

behavior is I expected. but tests are failing with my patch.

>From test_channel.vim:
Found errors in Test_out_close_cb():
function RunTheTest[9]..Test_out_close_cb line 26: Expected 2 but got 0
Found errors in Test_pipe_to_buffer_name():
function RunTheTest[9]..Test_pipe_to_buffer_name[1]..Run_test_pipe_to_buffer 
line 35: Expected 'yes' but got 'no'
Found errors in Test_pipe_to_buffer_name_nomod():
Caught exception in Test_pipe_to_buffer_name_nomod(): Vim(sleep):E117: Unknown 
function: CloseHandler @ function 
RunTheTest[9]..Test_pipe_to_buffer_name_nomod[1]..Run_test_pipe_to_buffer[28]..WaitFor,
 line 20
Found errors in Test_read_in_close_cb():
function RunTheTest[9]..Test_read_in_close_cb line 15: Expected 'quit' but got 
''

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