Re: Odd behavior of vim 8.0.1203 in a wide xterm -- solution found

2017-11-02 Fir de Conversatie Gary Johnson
On 2017-11-02, Gary Johnson wrote:

> So the funny behavior does seem related to the old addressing
> style, but why is it happening on an xterm-318 with 'ttymouse'
> automatically set to "sgr"?

I tried finding the problem by bisecting the repository and found
that my build of 7.4.160 failed, too.  That led me to discover that
my normal build was missing the mouse_sgr feature.  I added
-DFEAT_MOUSE_SGR to CFLAGS and rebuilt and all is good.

Thanks to James McCoy for directing my attention to SGR.

Regards,
Gary

-- 
-- 
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: [doc][patch] Update documents

2017-11-02 Fir de Conversatie Ken Takata
Hi Bram,

2017/10/28 Sat 4:19:49 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > The following help items describe similar things:
> > 
> >   :help gui-w32-cmdargs
> >   :help win32-quotes
> > 
> > I think they can be merged.  Moreover, they doesn't reflect the change by
> > the patch 7.4.432.  Please check the attached patch.
> > (Related: https://github.com/vim/vim/issues/670)
> 
> Thanks, I'll include it.

Thank you for merging the patches in this thread.  However it seems that some
of the patches are not included.
Could you check the attached patch?

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  09321603d438104544684ddfa2e73914a3e502bf

diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -2074,7 +2074,7 @@ ch_setoptions({handle}, {options})
 ch_status({handle} [, {options}])
 String	status of channel {handle}
 changenr()			Number	current change number
-char2nr({expr}[, {utf8}])	Number	ASCII/UTF8 value of first char in {expr}
+char2nr({expr} [, {utf8}])	Number	ASCII/UTF8 value of first char in {expr}
 cindent({lnum})			Number	C indent for line {lnum}
 clearmatches()			none	clear all matches
 col({expr})			Number	column nr of cursor or mark
@@ -2116,9 +2116,9 @@ filereadable({file})		Number	|TRUE| if {
 filewritable({file})		Number	|TRUE| if {file} is a writable file
 filter({expr1}, {expr2})	List/Dict  remove items from {expr1} where
 	{expr2} is 0
-finddir({name}[, {path}[, {count}]])
+finddir({name} [, {path} [, {count}]])
 String	find directory {name} in {path}
-findfile({name}[, {path}[, {count}]])
+findfile({name} [, {path} [, {count}]])
 String	find file {name} in {path}
 float2nr({expr})		Number	convert Float {expr} to a Number
 floor({expr})			Float	round {expr} down
@@ -2162,7 +2162,7 @@ getftime({fname})		Number	last modificat
 getftype({fname})		String	description of type of file {fname}
 getline({lnum})			String	line {lnum} of current buffer
 getline({lnum}, {end})		List	lines {lnum} to {end} of current buffer
-getloclist({nr}[, {what}])	List	list of location list items
+getloclist({nr} [, {what}])	List	list of location list items
 getmatches()			List	list of current matches
 getpackages([{packname} [, {packtype} [, {plugname} [, {nameonly})
 List	list of pakage/plugin directories
@@ -2240,28 +2240,28 @@ lispindent({lnum})		Number	Lisp indent f
 localtime()			Number	current time
 log({expr})			Float	natural logarithm (base e) of {expr}
 log10({expr})			Float	logarithm of Float {expr} to base 10
-luaeval({expr}[, {expr}])	any	evaluate |Lua| expression
+luaeval({expr} [, {expr}])	any	evaluate |Lua| expression
 map({expr1}, {expr2})		List/Dict  change each item in {expr1} to {expr}
-maparg({name}[, {mode} [, {abbr} [, {dict}]]])
+maparg({name} [, {mode} [, {abbr} [, {dict}]]])
 String or Dict
 	rhs of mapping {name} in mode {mode}
-mapcheck({name}[, {mode} [, {abbr}]])
+mapcheck({name} [, {mode} [, {abbr}]])
 String	check for mappings matching {name}
-match({expr}, {pat}[, {start}[, {count}]])
+match({expr}, {pat} [, {start} [, {count}]])
 Number	position where {pat} matches in {expr}
-matchadd({group}, {pattern}[, {priority}[, {id} [, {dict}]]])
+matchadd({group}, {pattern} [, {priority} [, {id} [, {dict}]]])
 Number	highlight {pattern} with {group}
-matchaddpos({group}, {pos}[, {priority}[, {id}[, {dict}]]])
+matchaddpos({group}, {pos} [, {priority} [, {id} [, {dict}]]])
 Number	highlight positions with {group}
 matcharg({nr})			List	arguments of |:match|
 matchdelete({id})		Number	delete match identified by {id}
-matchend({expr}, {pat}[, {start}[, {count}]])
+matchend({expr}, {pat} [, {start} [, {count}]])
 Number	position where {pat} ends in {expr}
-matchlist({expr}, {pat}[, {start}[, {count}]])
+matchlist({expr}, {pat} [, {start} [, {count}]])
 List	match and submatches of {pat} in {expr}
-matchstr({expr}, {pat}[, {start}[, {count}]])
+matchstr({expr}, {pat} [, {start} [, {count}]])
 String	{count}'th match of {pat} in {expr}
-matchstrpos({expr}, {pat}[, {start}[, {count}]])
+matchstrpos({expr}, {pat} [, {start} [, {count}]])
 List	{count}'th match of {pat} in {expr}
 max({expr})			Number	maximum value of items in {expr}
 min({expr})			Number	minimum value of items in {expr}
@@ -2270,7 +2270,7 @@ mkdir({name} [, {path} [, {prot}]])
 mode([expr])			String	current editing mode
 mzeval({expr})			any	evaluate |MzScheme| expression
 nextnonblank({lnum})		Number	line nr of non-blank line >= 

Re: Security risk of vim swap files

2017-11-02 Fir de Conversatie Marvin Renich
* Christian Brabandt  [171102 16:50]:
> 
> On Do, 02 Nov 2017, z...@z5t1.com wrote:
> 
> > 
> > However, there is another problem with the swap file permissions
> > that has not yet been discussed: when Vim creates swap files, the
> > .swp file is created with the owner and group set to the user who is
> > editing the file (hereafter referred to as the "editor") and the
> > editor's primary group respectively. The permission bits on the swap
> > file are the same as the original file.
> > 
> > This is a problem, as the editor's primary group may be different
> > from the group of the file being edited. Take /etc/shadow for
> > example. That file is supposed to have the permissions 640 with
> > owner: root, group: shadow as a quick `ls -l` shows:
> > 
> > -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow
> > 
> > However, shadow is not the root user's primary group; on this system
> > it happens to be 'users', which every other user on the system is
> > also a member of. Now if root goes to edit the file, a swap file is
> > created in /etc/.shadow.swp with the following permissions:
> > 
> > -rw-r- 1 root users 4096 Nov  2 13:52 /etc/.shadow.swp
> > 
> > This swap file is now readable by every user on the system. Keep in
> > mind the /etc/shadow file contains hashes of every user's password,
> > so now the password for every single user on the system may have
> > been compromised.
> 
> That looks like a problem.

I agree.  One solution is if the user doing the editing has permission
to create the swap file with the original file's user:group, then do
that with the original file's perms.  Otherwise use the editing user's
user:group and perm 0600.

Another solution would be to always use the editing user's user:group
and perm 0600.

There might need to be more logic added to recover to check if the
current user has rw permission on the swap file.  However, this might
very well just 'work' (i.e. fail gracefully) with the current code.

Re Bram's question about root's default group being users:  While that
seems like a bad idea in general, the situation could still come up with
very reasonable user/group combinations.  Take a 'normal' user whose
default group is users, but who also happens to be a member of group
staff.  A file with root:staff ownership and 0660 perms would have a
swap file with someone:users and perms 0660, thus giving most users rw
access to the swap file when they had neither r nor w access to the
original.

...Marvin

-- 
-- 
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: Odd behavior of vim 8.0.1203 in a wide xterm

2017-11-02 Fir de Conversatie Gary Johnson
Yet another experiment:

This Linux distribution comes with vim 7.4.160 in /usr/bin/vim, so
I repeated the experiments I tried before and it worked just fine in
all cases.  So the problem is with vim, not its environment, and it
was introduced sometime between 7.4.160 and 8.0.1203.

Regards,
Gary

-- 
-- 
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: Odd behavior of vim 8.0.1203 in a wide xterm

2017-11-02 Fir de Conversatie Gary Johnson
I tried another experiment.  This time I just opened vim with
a single window and filled a couple of lines with text.  Then
I used the mouse to position the cursor.  I could move the
cursor as far right as column 223, but moving the mouse pointer
any further to the right and clicking the mouse moved the cursor
to column 1.

So the funny behavior does seem related to the old addressing
style, but why is it happening on an xterm-318 with 'ttymouse'
automatically set to "sgr"?

Regards,
Gary

-- 
-- 
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: Odd behavior of vim 8.0.1203 in a wide xterm

2017-11-02 Fir de Conversatie Gary Johnson
On 2017-11-02, James McCoy wrote:
> On Thu, Nov 02, 2017 at 04:03:32PM -0700, Gary Johnson wrote:
> > I opened an xterm and dragged it to the full width of my two
> > monitors.
> > 
> > $ echo $LINES $COLUMNS
> > 50 370
> 
> Vim must not be detecting that your terminal can support newer mouse
> addressing modes like urxvt or sgr.  See :help 'ttymouse'.  When
> 'ttymouse' isn't urxvt or sgr, then you run into the 223 column
> limitation of the old addressing style.
> 
> You should be able to use ttymouse=sgr, assuming you have an xterm
> version > 277.

:ttymouse?
  ttymouse=sgr

My xterm version is 318.  Thanks for the suggestion, though.

If if matters, I'm running X on Linux remotely from a Windows
7 machine using TigerVNC.

Regards,
Gary

-- 
-- 
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: Odd behavior of vim 8.0.1203 in a wide xterm

2017-11-02 Fir de Conversatie James McCoy
On Thu, Nov 02, 2017 at 04:03:32PM -0700, Gary Johnson wrote:
> I opened an xterm and dragged it to the full width of my two
> monitors.
> 
> $ echo $LINES $COLUMNS
> 50 370

Vim must not be detecting that your terminal can support newer mouse
addressing modes like urxvt or sgr.  See :help 'ttymouse'.  When
'ttymouse' isn't urxvt or sgr, then you run into the 223 column
limitation of the old addressing style.

You should be able to use ttymouse=sgr, assuming you have an xterm
version > 277.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

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


Odd behavior of vim 8.0.1203 in a wide xterm

2017-11-02 Fir de Conversatie Gary Johnson
I opened an xterm and dragged it to the full width of my two
monitors.

$ echo $LINES $COLUMNS
50 370

Then I opened vim with four vertical windows:

$ vim -N -u NONE -i NONE -O4 -c 'set mouse=a'

There are several problems with the resulting display.

Problem 1:

I cannot drag the vertical separator between the third and fourth
windows.

Problem 2:

When I drag the vertical separator between the second and third
windows to the right, it works fine until I've dragged it about 20
columns.  Then it suddenly snaps to the left so that the widths of
the first and second windows are 1 each, the width of the third
window is 274, and the width of the fourth window has remained 91.

Problem 3:

I cannot select the fourth window using the mouse.  I can click in
any of the first three windows and that window is selected, but
clicking in the fourth window selects the first window.


Running Vim 8.0.1203, normal version with GTK2 GUI, in an xterm
version 318, on Red Hat Enterprise Linux Server release 7.2.

Regards,
Gary

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1257 (after 8.0.1254)
Problem:No test for fix of undefined behavior.
Solution:   Add a test. (closes #2255)
Files:  src/testdir/test_search.vim


*** ../vim-8.0.1256/src/testdir/test_search.vim 2017-11-02 19:08:39.741514601 
+0100
--- src/testdir/test_search.vim 2017-11-02 23:10:15.853493380 +0100
***
*** 697,699 
--- 697,703 
call term_sendkeys(g:buf, ":qa!\")
bwipe!
  endfunc
+ 
+ func Test_search_undefined_behaviour2()
+   call search("\%UC000")
+ endfunc
*** ../vim-8.0.1256/src/version.c   2017-11-02 23:04:10.503700153 +0100
--- src/version.c   2017-11-02 23:06:55.686702457 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1257,
  /**/

-- 
Biting someone with your natural teeth is "simple assault," while biting
someone with your false teeth is "aggravated assault."
[real standing law in Louisana, United States of America]

 /// 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: Security risk of vim swap files

2017-11-02 Fir de Conversatie Z5T1
Thank you Christian; I'm tweaking my configuration as you suggested.


On 11/02/17 16:50, Christian Brabandt wrote:
>
> What is with files that are edited by several users possibly at the same 
> time? They won't get a warning message now.
I thought about this. As I said, my fix has some issues. One possible
solution I thought of was modifying vim to create a .filename.lock file
in the directory of the file you are editing, but with nothing in it.
Vim can the check for the existence of a .lock file to determine if the
file is locked for editing, and further check the owner of that file to
determine who has locked the file for editing. This still allows for vim
to prevent multiple users from inadvertently editing the same file at
once without risking disclosing the file contents to unintended parties.
If I get a chance, I will try to write a patch doing this.


On 11/02/17 16:50, Christian Brabandt wrote:
> On Do, 02 Nov 2017, z...@z5t1.com wrote:
>
>> However, there is another problem with the swap file permissions that has 
>> not yet been discussed: when Vim creates swap files, the .swp file is 
>> created with the owner and group set to the user who is editing the file 
>> (hereafter referred to as the "editor") and the editor's primary group 
>> respectively. The permission bits on the swap file are the same as the 
>> original file.
>>
>> This is a problem, as the editor's primary group may be different from the 
>> group of the file being edited. Take /etc/shadow for example. That file is 
>> supposed to have the permissions 640 with owner: root, group: shadow as a 
>> quick `ls -l` shows:
>>
>> -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow
>>
>> However, shadow is not the root user's primary group; on this system it 
>> happens to be 'users', which every other user on the system is also a member 
>> of. Now if root goes to edit the file, a swap file is created in 
>> /etc/.shadow.swp with the following permissions:
>>
>> -rw-r- 1 root users 4096 Nov  2 13:52 /etc/.shadow.swp
>>
>> This swap file is now readable by every user on the system. Keep in mind the 
>> /etc/shadow file contains hashes of every user's password, so now the 
>> password for every single user on the system may have been compromised.
> That looks like a problem.
>
>> --- Solution ---
>>
>> I have found this problem can be mitigated by changing the swap directory 
>> with the 'set directory' directive as Hanno originally suggested. I have 
>> added the following lines to my '/etc/vimrc':
>>
>> " Move the swap file location to protect against CVE-2017-1000382
>> silent !install -d -m 700 ~/.vim/swap/ 2>&1 > /dev/null
> you likely want to add a check if the directory exists, so that not 
> every time Vim is called, it needs to shell out. Note, there is also 
> `system()` available. See `:h isdirectory()` and `:h system()`
>
>> set directory=~/.vim/swap/
> ,[ :h 'directory' ]-
> | - For Unix and Win32, if a directory ends in two path separators "//"
> |   or "\\", the swap file name will be built from the complete path to
> |   the file with all path separators substituted to percent '%' signs.
> |   This will ensure file name uniqueness in the preserve directory.
> `
>
>> This safely sets the swap file directory to a directory that should
>> not cause any security problems. For added security, the directory is
>> created so that only the owner has access to it, regardless of how the
>> system's umask or .swp file permissions are set.
> What is with files that are edited by several users possibly at the same 
> time? They won't get a warning message now.
>
>> Additionally, the swap file collision (if you edit both ~/foo/file and
>> ~/bar/file at the same time) is not a major issue; Vim detects this
>> and gives the second swap file a different file extension. When you go
>> to restore from the swap file, you get a prompt asking which swap file
>> you want to use (if there are two swap files with the same basename),
>> which doesn't strike me as being terribly problematic. While this
>> approach may have some minor issues/quirks, for me it seems far
>> preferable to being vulnerable to this vulnerability.
> And how do you know from which swap file to recover? Additionally, if 
> there is ~/.vim/swap/.foo.txt.swp and ~/.vim/swap/.foo.txt.swo and the 
> first swap file is removed (after the editing session finishes), you 
> won't get a swap file recovery message anymore when editing a file for 
> which only ~/.vim/swap/.foo.txt.swo exists.
>
>> I have already applied this fix on Cucumber Linux and thought you may
>> want to consider applying a similar fix upstream.
> You might want to tweak your setting as mentioned above.
>
> 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 

Patch 8.0.1256

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1256
Problem:Typo in configure variable vim_cv_tgent. (Matthieu Guillard)
Solution:   Rename the variable. (closes #2281)
Files:  src/configure.ac, src/auto/configure


*** ../vim-8.0.1255/src/configure.ac2017-10-28 21:08:38.975457036 +0200
--- src/configure.ac2017-11-02 23:01:22.824712867 +0100
***
*** 3388,3394 
AC_DEFINE(TERMINFO)
  fi
  
! AC_CACHE_CHECK([what tgetent() returns for an unknown terminal], 
[vim_cv_tgent],
[
  AC_RUN_IFELSE([AC_LANG_SOURCE([[
  #include "confdefs.h"
--- 3388,3394 
AC_DEFINE(TERMINFO)
  fi
  
! AC_CACHE_CHECK([what tgetent() returns for an unknown terminal], 
[vim_cv_tgetent],
[
  AC_RUN_IFELSE([AC_LANG_SOURCE([[
  #include "confdefs.h"
***
*** 3402,3416 
  main()
  {char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); exit(res != 
0); }
  ]])],[
!   vim_cv_tgent=zero
  ],[
!   vim_cv_tgent=non-zero
  ],[
AC_MSG_ERROR(failed to compile test program.)
  ])
])
  
! if test "x$vim_cv_tgent" = "xzero" ; then
AC_DEFINE(TGETENT_ZERO_ERR, 0)
  fi
  
--- 3402,3416 
  main()
  {char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); exit(res != 
0); }
  ]])],[
!   vim_cv_tgetent=zero
  ],[
!   vim_cv_tgetent=non-zero
  ],[
AC_MSG_ERROR(failed to compile test program.)
  ])
])
  
! if test "x$vim_cv_tgetent" = "xzero" ; then
AC_DEFINE(TGETENT_ZERO_ERR, 0)
  fi
  
*** ../vim-8.0.1255/src/auto/configure  2017-10-28 21:08:38.975457036 +0200
--- src/auto/configure  2017-11-02 23:02:57.148143199 +0100
***
*** 11553,11559 
  
  { $as_echo "$as_me:${as_lineno-$LINENO}: checking what tgetent() returns for 
an unknown terminal" >&5
  $as_echo_n "checking what tgetent() returns for an unknown terminal... " >&6; 
}
! if ${vim_cv_tgent+:} false; then :
$as_echo_n "(cached) " >&6
  else
  
--- 11553,11559 
  
  { $as_echo "$as_me:${as_lineno-$LINENO}: checking what tgetent() returns for 
an unknown terminal" >&5
  $as_echo_n "checking what tgetent() returns for an unknown terminal... " >&6; 
}
! if ${vim_cv_tgetent+:} false; then :
$as_echo_n "(cached) " >&6
  else
  
***
*** 11579,11589 
  _ACEOF
  if ac_fn_c_try_run "$LINENO"; then :
  
!   vim_cv_tgent=zero
  
  else
  
!   vim_cv_tgent=non-zero
  
  fi
  rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
--- 11579,11589 
  _ACEOF
  if ac_fn_c_try_run "$LINENO"; then :
  
!   vim_cv_tgetent=zero
  
  else
  
!   vim_cv_tgetent=non-zero
  
  fi
  rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
***
*** 11592,11601 
  
  
  fi
! { $as_echo "$as_me:${as_lineno-$LINENO}: result: $vim_cv_tgent" >&5
! $as_echo "$vim_cv_tgent" >&6; }
  
! if test "x$vim_cv_tgent" = "xzero" ; then
$as_echo "#define TGETENT_ZERO_ERR 0" >>confdefs.h
  
  fi
--- 11592,11601 
  
  
  fi
! { $as_echo "$as_me:${as_lineno-$LINENO}: result: $vim_cv_tgetent" >&5
! $as_echo "$vim_cv_tgetent" >&6; }
  
! if test "x$vim_cv_tgetent" = "xzero" ; then
$as_echo "#define TGETENT_ZERO_ERR 0" >>confdefs.h
  
  fi
*** ../vim-8.0.1255/src/version.c   2017-11-02 22:38:47.820893348 +0100
--- src/version.c   2017-11-02 23:03:14.604037771 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1256,
  /**/

-- 
It is illegal to rob a bank and then shoot at the bank teller with a water
pistol.
[real standing law in Louisana, United States of America]

 /// 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: Security risk of vim swap files

2017-11-02 Fir de Conversatie Bram Moolenaar

z5t1 (???) wrote:

> Hi, I'd like to add my two cents to this.
> 
> I have reproduced this on Centos 6 and Cucumber Linux 1.0. We have 
> established that the umask plays no role in the permissions on swap files; 
> Vim creates its swap files with the same permissions as the file being edited.
> 
> However, there is another problem with the swap file permissions that has not 
> yet been discussed: when Vim creates swap files, the .swp file is created 
> with the owner and group set to the user who is editing the file (hereafter 
> referred to as the "editor") and the editor's primary group respectively. The 
> permission bits on the swap file are the same as the original file.
> 
> This is a problem, as the editor's primary group may be different from the 
> group of the file being edited. Take /etc/shadow for example. That file is 
> supposed to have the permissions 640 with owner: root, group: shadow as a 
> quick `ls -l` shows:
> 
> -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow
> 
> However, shadow is not the root user's primary group; on this system it 
> happens to be 'users', which every other user on the system is also a member 
> of. Now if root goes to edit the file, a swap file is created in 
> /etc/.shadow.swp with the following permissions:
> 
> -rw-r- 1 root users 4096 Nov  2 13:52 /etc/.shadow.swp
> 
> This swap file is now readable by every user on the system. Keep in mind the 
> /etc/shadow file contains hashes of every user's password, so now the 
> password for every single user on the system may have been compromised.

Eh, why is root's primary group one that all users on the system are a
member of?  That is asking for trouble.  Every file that root creates
will be readable by everybody by default.

> --- Solution ---
> 
> I have found this problem can be mitigated by changing the swap directory 
> with the 'set directory' directive as Hanno originally suggested. I have 
> added the following lines to my '/etc/vimrc':
> 
> " Move the swap file location to protect against CVE-2017-1000382
> silent !install -d -m 700 ~/.vim/swap/ 2>&1 > /dev/null
> set directory=~/.vim/swap/
> 
> This safely sets the swap file directory to a directory that should not cause 
> any security problems. For added security, the directory is created so that 
> only the owner has access to it, regardless of how the system's umask or .swp 
> file permissions are set.
> 
> Additionally, the swap file collision (if you edit both ~/foo/file and 
> ~/bar/file at the same time) is not a major issue; Vim detects this and gives 
> the second swap file a different file extension. When you go to restore from 
> the swap file, you get a prompt asking which swap file you want to use (if 
> there are two swap files with the same basename), which doesn't strike me as 
> being terribly problematic. While this approach may have some minor 
> issues/quirks, for me it seems far preferable to being vulnerable to this 
> vulnerability.
> 
> I have already applied this fix on Cucumber Linux and thought you may want to 
> consider applying a similar fix upstream.

-- 
Kisses may last for as much as, but no more than, five minutes.
[real standing law in Iowa, United States of America]

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Dominique wrote:

> > Patch 8.0.1248 (after 8.0.1247)
> > Problem:Stray + in README file.
> > Solution:   Remove the +.  Add a line break.
> > Files:  README.md
> 
> 
> The debian badge was put twice somehow in README.md
> Sorry about that. Fixed in attached patch.

I also missed it.

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

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1255 (after 8.0.1248)
Problem:duplicate badge README file.
Solution:   Remove one. (Dominique Pelle)
Files:  README.md


*** ../vim-8.0.1254/README.md   2017-11-02 18:12:56.097119507 +0100
--- README.md   2017-11-02 22:37:01.921530987 +0100
***
*** 5,11 
  [![Coverage 
Status](https://coveralls.io/repos/vim/vim/badge.svg?branch=master=github)](https://coveralls.io/github/vim/vim?branch=master)
  [![Appveyor Build 
status](https://ci.appveyor.com/api/projects/status/o2qht2kjm02sgghk?svg=true)](https://ci.appveyor.com/project/chrisbra/vim)
  [![Coverity 
Scan](https://scan.coverity.com/projects/241/badge.svg)](https://scan.coverity.com/projects/vim)
! [![Debian 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)[![Debian
 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)
  
  
  ## What is Vim? ##
--- 5,11 
  [![Coverage 
Status](https://coveralls.io/repos/vim/vim/badge.svg?branch=master=github)](https://coveralls.io/github/vim/vim?branch=master)
  [![Appveyor Build 
status](https://ci.appveyor.com/api/projects/status/o2qht2kjm02sgghk?svg=true)](https://ci.appveyor.com/project/chrisbra/vim)
  [![Coverity 
Scan](https://scan.coverity.com/projects/241/badge.svg)](https://scan.coverity.com/projects/vim)
! [![Debian 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)
  
  
  ## What is Vim? ##
*** ../vim-8.0.1254/src/version.c   2017-11-02 22:29:32.840234120 +0100
--- src/version.c   2017-11-02 22:37:49.493244559 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1255,
  /**/

-- 
How do you know when you have run out of invisible ink?

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1254
Problem:Undefined left shift in gethexchrs(). (geeknik)
Solution:   Use unsigned long. (idea by Christian Brabandt, closes #2255)
Files:  src/regexp.c, src/regexp_nfa.c


*** ../vim-8.0.1253/src/regexp.c2017-10-24 21:49:32.234837736 +0200
--- src/regexp.c2017-11-02 22:18:35.864197402 +0100
***
*** 695,703 
  static intpeekchr(void);
  static void   skipchr(void);
  static void   ungetchr(void);
! static intgethexchrs(int maxinputlen);
! static intgetoctchrs(void);
! static intgetdecchrs(void);
  static intcoll_get_char(void);
  static void   regcomp_start(char_u *expr, int flags);
  static char_u *reg(int, int *);
--- 695,703 
  static intpeekchr(void);
  static void   skipchr(void);
  static void   ungetchr(void);
! static long   gethexchrs(int maxinputlen);
! static long   getoctchrs(void);
! static long   getdecchrs(void);
  static intcoll_get_char(void);
  static void   regcomp_start(char_u *expr, int flags);
  static char_u *reg(int, int *);
***
*** 1837,1843 
case Magic('@'):
{
int lop = END;
!   int nr;
  
nr = getdecchrs();
switch (no_Magic(getchr()))
--- 1837,1843 
case Magic('@'):
{
int lop = END;
!   longnr;
  
nr = getdecchrs();
switch (no_Magic(getchr()))
***
*** 2278,2284 
case 'u':   /* %uabcd hex 4 */
case 'U':   /* %U1234abcd hex 8 */
  {
! int i;
  
  switch (c)
  {
--- 2278,2284 
case 'u':   /* %uabcd hex 4 */
case 'U':   /* %U1234abcd hex 8 */
  {
! long i;
  
  switch (c)
  {
***
*** 3274,3283 
   * The parameter controls the maximum number of input characters. This will be
   * 2 when reading a \%x20 sequence and 4 when reading a \%u20AC sequence.
   */
! static int
  gethexchrs(int maxinputlen)
  {
! int   nr = 0;
  int   c;
  int   i;
  
--- 3274,3283 
   * The parameter controls the maximum number of input characters. This will be
   * 2 when reading a \%x20 sequence and 4 when reading a \%u20AC sequence.
   */
! static long
  gethexchrs(int maxinputlen)
  {
! long_unr = 0;
  int   c;
  int   i;
  
***
*** 3293,3309 
  
  if (i == 0)
return -1;
! return nr;
  }
  
  /*
   * Get and return the value of the decimal string immediately after the
   * current position. Return -1 for invalid.  Consumes all digits.
   */
! static int
  getdecchrs(void)
  {
! int   nr = 0;
  int   c;
  int   i;
  
--- 3293,3309 
  
  if (i == 0)
return -1;
! return (long)nr;
  }
  
  /*
   * Get and return the value of the decimal string immediately after the
   * current position. Return -1 for invalid.  Consumes all digits.
   */
! static long
  getdecchrs(void)
  {
! long_unr = 0;
  int   c;
  int   i;
  
***
*** 3320,3326 
  
  if (i == 0)
return -1;
! return nr;
  }
  
  /*
--- 3320,3326 
  
  if (i == 0)
return -1;
! return (long)nr;
  }
  
  /*
***
*** 3331,3340 
   * blahblah\%o210asdf
   *   before-^  ^-after
   */
! static int
  getoctchrs(void)
  {
! int   nr = 0;
  int   c;
  int   i;
  
--- 3331,3340 
   * blahblah\%o210asdf
   *   before-^  ^-after
   */
! static long
  getoctchrs(void)
  {
! long_unr = 0;
  int   c;
  int   i;
  
***
*** 3350,3356 
  
  if (i == 0)
return -1;
! return nr;
  }
  
  /*
--- 3350,3356 
  
  if (i == 0)
return -1;
! return (long)nr;
  }
  
  /*
***
*** 3360,3366 
  static int
  coll_get_char(void)
  {
! int   nr = -1;
  
  switch (*regparse++)
  {
--- 3360,3366 
  static int
  coll_get_char(void)
  {
! long  nr = -1;
  
  switch (*regparse++)
  {
*** ../vim-8.0.1253/src/regexp_nfa.c2017-10-24 21:49:32.234837736 +0200
--- src/regexp_nfa.c2017-11-02 22:22:26.954796218 +0100
***
*** 1522,1528 
case 'u':   /* %uabcd hex 4 */
case 'U':   /* %U1234abcd hex 8 */
{
!   int nr;
  
switch (c)
{
--- 1522,1528 
case 'u':   /* %uabcd hex 4 */
case 'U':   /* %U1234abcd hex 

Re: Security risk of vim swap files

2017-11-02 Fir de Conversatie Christian Brabandt

On Do, 02 Nov 2017, z...@z5t1.com wrote:

> 
> However, there is another problem with the swap file permissions that has not 
> yet been discussed: when Vim creates swap files, the .swp file is created 
> with the owner and group set to the user who is editing the file (hereafter 
> referred to as the "editor") and the editor's primary group respectively. The 
> permission bits on the swap file are the same as the original file.
> 
> This is a problem, as the editor's primary group may be different from the 
> group of the file being edited. Take /etc/shadow for example. That file is 
> supposed to have the permissions 640 with owner: root, group: shadow as a 
> quick `ls -l` shows:
> 
> -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow
> 
> However, shadow is not the root user's primary group; on this system it 
> happens to be 'users', which every other user on the system is also a member 
> of. Now if root goes to edit the file, a swap file is created in 
> /etc/.shadow.swp with the following permissions:
> 
> -rw-r- 1 root users 4096 Nov  2 13:52 /etc/.shadow.swp
> 
> This swap file is now readable by every user on the system. Keep in mind the 
> /etc/shadow file contains hashes of every user's password, so now the 
> password for every single user on the system may have been compromised.

That looks like a problem.

> 
> --- Solution ---
> 
> I have found this problem can be mitigated by changing the swap directory 
> with the 'set directory' directive as Hanno originally suggested. I have 
> added the following lines to my '/etc/vimrc':
> 
> " Move the swap file location to protect against CVE-2017-1000382
> silent !install -d -m 700 ~/.vim/swap/ 2>&1 > /dev/null

you likely want to add a check if the directory exists, so that not 
every time Vim is called, it needs to shell out. Note, there is also 
`system()` available. See `:h isdirectory()` and `:h system()`

> set directory=~/.vim/swap/

,[ :h 'directory' ]-
| - For Unix and Win32, if a directory ends in two path separators "//"
|   or "\\", the swap file name will be built from the complete path to
|   the file with all path separators substituted to percent '%' signs.
|   This will ensure file name uniqueness in the preserve directory.
`

> This safely sets the swap file directory to a directory that should
> not cause any security problems. For added security, the directory is
> created so that only the owner has access to it, regardless of how the
> system's umask or .swp file permissions are set.

What is with files that are edited by several users possibly at the same 
time? They won't get a warning message now.

> Additionally, the swap file collision (if you edit both ~/foo/file and
> ~/bar/file at the same time) is not a major issue; Vim detects this
> and gives the second swap file a different file extension. When you go
> to restore from the swap file, you get a prompt asking which swap file
> you want to use (if there are two swap files with the same basename),
> which doesn't strike me as being terribly problematic. While this
> approach may have some minor issues/quirks, for me it seems far
> preferable to being vulnerable to this vulnerability.

And how do you know from which swap file to recover? Additionally, if 
there is ~/.vim/swap/.foo.txt.swp and ~/.vim/swap/.foo.txt.swo and the 
first swap file is removed (after the editing session finishes), you 
won't get a swap file recovery message anymore when editing a file for 
which only ~/.vim/swap/.foo.txt.swo exists.

> I have already applied this fix on Cucumber Linux and thought you may
> want to consider applying a similar fix upstream.

You might want to tweak your setting as mentioned above.

Christian 
-- 
Die Welt ist eine Glocke, die einen Riss hat: Sie klappert, aber 
klingt nicht.
-- Goethe, Maximen und Reflektionen, Nr. 333

-- 
-- 
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: Security risk of vim swap files

2017-11-02 Fir de Conversatie z5t1
On Thursday, November 2, 2017 at 9:09:49 AM UTC-4, Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > 2017/11/1 Wed 6:20:27 UTC+9 Bram Moolenaar wrote:
> > > Hanno Böck wrote:
> > > 
> > > > I wanted to point out an issue here with vim swap files that make them
> > > > a security problem.
> > > > 
> > > > By default vim creates a file with the name .filename.swp in the same
> > > > directory while editing. They contain the full content of the edited
> > > > file. This usually gets deleted upon exit, but not if vim crashes or
> > > > gets killed (e.g. due to a reboot).
> > > > 
> > > > On web servers this can be a severe security risk. One can e.g. scan
> > > > for web hosts that have swap files of PHP configuration files and thus
> > > > expose settings like database passwords. (e.g. wget
> > > > http://example.com/.wp-config.php.swp )
> > > 
> > > Why would a web server expose and serve such a file?  That clearly is
> > > the problem, not that Vim happens to create swap files (and undo and
> > > backup files, depending on your configuration).
> > > 
> > > You probably also create new files and copies of files that should not
> > > be served.  If you care about security, the web server must always use
> > > whitelisting, only serve files that were intentionally made public.
> > > 
> > > > In a scan of the alexa top 1 million I found ~750 instances of such
> > > > files. I tried to inform affected people as best as I could. I also
> > > > discovered such scans in my own web server logs, so I assume black hats
> > > > are already aware of this and it's actively exploitet.
> > > > 
> > > > I was wondering how to best avoid this on my own servers and I first
> > > > thought about saving the swap files to tmp ( with "set directory").
> > > > However on multiuser systems this creates another security problem.
> > > > These files are world readable, thus instead of leaking information to
> > > > the world it's now leaking information to other users on the same
> > > > system. Thus even if one is aware of the issue it's nontrivial to get
> > > > secure settings (I've now worked around this by having per-user tmp
> > > > dirs with secure permissions.)
> > > > 
> > > > I think vim should change the behavior of swap files:
> > > > 1. they should be stored in /tmp by default
> > > 
> > > No, on Linux this is wiped clean on reboot.  You lose your work on a
> > > system crash.
> > > 
> > > > 2. they should have secure permissions (tmp file security is
> > > > a tricky thing and needs careful consideration to avoid symlink attacks
> > > > and the like, but there are dedicated functions for this like mkstemp).
> > > 
> > > The permissions are the same as the original file, and that is exactly
> > > how it should be.
> > > 
> > > > 3. Ideally they also shouldn't leak currently edited filenames (e.g.
> > > > they shouldn't be called /tmp/.test.txt.swp, but more something
> > > > like /tmp/.vim_swap.123782173)
> > > 
> > > Infeasible, Vim can't find that file when trying to recover the original
> > > file.
> > 
> > An issue related to this (not the same) is filed as CVE-2017-1000382:
> >   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000382
> >   https://security-tracker.debian.org/tracker/CVE-2017-1000382
> > 
> > It seems that the problem is that Vim ignores umask:
> >   http://www.openwall.com/lists/oss-security/2017/10/31/15
> > 
> > (Similar one for Emacs:
> >   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383 )
> 
> This is working as intended, Vim does not use umask this way.
> Umask is only used by simple commands such as cp, not by long running
> processes that deal with many files.
> 
> Problem is with the user expectations.
> 
> -- 
> Permission is granted to read this message out aloud on Kings Cross Road,
> London, under the condition that the orator is properly dressed.
> 
>  /// 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///

Hi, I'd like to add my two cents to this.

I have reproduced this on Centos 6 and Cucumber Linux 1.0. We have established 
that the umask plays no role in the permissions on swap files; Vim creates its 
swap files with the same permissions as the file being edited.

However, there is another problem with the swap file permissions that has not 
yet been discussed: when Vim creates swap files, the .swp file is created with 
the owner and group set to the user who is editing the file (hereafter referred 
to as the "editor") and the editor's primary group respectively. The permission 
bits on the swap file are the same as the original file.

This is a problem, as the editor's primary group may be different from the 
group of the file being edited. Take /etc/shadow for example. That file is 
supposed to have the 

Patch 8.0.1253

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1253
Problem:Still too many old style tests.
Solution:   Convert a few more tests to new style. (Yegappan Lakshmanan,
closes #2272)
Files:  src/Makefile, src/testdir/Make_all.mak,
src/testdir/Make_amiga.mak, src/testdir/Make_dos.mak,
src/testdir/Make_ming.mak, src/testdir/Make_vms.mms,
src/testdir/main.aap, src/testdir/test12.in,
src/testdir/test12.ok, src/testdir/test40.in,
src/testdir/test40.ok, src/testdir/test45.in,
src/testdir/test45.ok, src/testdir/test83.in,
src/testdir/test83.ok, src/testdir/test_autocmd.vim,
src/testdir/test_fold.vim, src/testdir/test_swap.vim,
src/testdir/test_tagjump.vim


*** ../vim-8.0.1252/src/Makefile2017-11-02 15:44:07.913903708 +0100
--- src/Makefile2017-11-02 20:58:54.169335263 +0100
***
*** 2103,2115 
test_listchars \
test_search_mbyte \
test_wordcount \
!   test3 test11 test12 test14 test15 test17 \
test29 test30 test36 test37 test39 \
!   test40 test42 test44 test45 test48 test49 \
test50 test52 test55 test59 \
test64 test68 test69 \
!   test70 test72 test73 test77 \
!   test83 test85 test86 test87 test88 \
test94 test95 test99 test108:
cd testdir; rm -f $@.out; $(MAKE) -f Makefile $@.out 
VIMPROG=../$(VIMTARGET) $(GUI_TESTARG) SCRIPTSOURCE=../$(SCRIPTSOURCE)
  
--- 2103,2115 
test_listchars \
test_search_mbyte \
test_wordcount \
!   test3 test11 test14 test15 test17 \
test29 test30 test36 test37 test39 \
!   test42 test44 test48 test49 \
test50 test52 test55 test59 \
test64 test68 test69 \
!   test70 test72 test73 \
!   test85 test86 test87 test88 \
test94 test95 test99 test108:
cd testdir; rm -f $@.out; $(MAKE) -f Makefile $@.out 
VIMPROG=../$(VIMTARGET) $(GUI_TESTARG) SCRIPTSOURCE=../$(SCRIPTSOURCE)
  
*** ../vim-8.0.1252/src/testdir/Make_all.mak2017-10-26 20:20:27.317598268 
+0200
--- src/testdir/Make_all.mak2017-11-02 20:58:54.169335263 +0100
***
*** 20,29 
test36.out \
test37.out \
test39.out \
-   test40.out \
test42.out \
test44.out \
-   test45.out \
test48.out \
test55.out \
test64.out \
--- 20,27 
***
*** 58,64 
  
  # Tests that run on most systems, but not on Amiga and DOS/Windows.
  SCRIPTS_MORE2 = \
-   test12.out \
test49.out
  
  
--- 56,61 
***
*** 68,74 
test30.out \
test59.out \
test72.out \
-   test83.out
  
  
  # Tests specifically for MS-Windows.
--- 65,70 
***
*** 79,85 
  SCRIPTS_GUI =
  
  
! # Tests using runtest.vim.vim.
  # Keep test_alot*.res as the last one, sort the others.
  NEW_TESTS = test_arabic.res \
test_arglist.res \
--- 75,81 
  SCRIPTS_GUI =
  
  
! # Tests using runtest.vim
  # Keep test_alot*.res as the last one, sort the others.
  NEW_TESTS = test_arabic.res \
test_arglist.res \
***
*** 164,169 
--- 160,166 
test_startup_utf8.res \
test_stat.res \
test_substitute.res \
+   test_swap.res \
test_syntax.res \
test_system.res \
test_tab.res \
*** ../vim-8.0.1252/src/testdir/Make_amiga.mak  2017-10-26 20:20:27.317598268 
+0200
--- src/testdir/Make_amiga.mak  2017-11-02 20:58:54.169335263 +0100
***
*** 13,19 
  # test2   "\\tmp" doesn't work
  # test10  'errorformat' is different
  # test11  "cat" doesn't work properly
- # test12  can't unlink a swap file
  # test52  only for Win32
  # test85  no Lua interface
  # test86, 87  no Python interface
--- 13,18 
*** ../vim-8.0.1252/src/testdir/Make_dos.mak2017-10-26 20:20:27.317598268 
+0200
--- src/testdir/Make_dos.mak2017-11-02 20:58:54.169335263 +0100
***
*** 12,18 
  # Omitted:
  # test2   "\\tmp" doesn't work.
  # test10  'errorformat' is different
- # test12  can't unlink a swap file
  # test49  fails in various ways
  # test97  \{ and \$ are not escaped characters.
  
--- 12,17 
*** ../vim-8.0.1252/src/testdir/Make_ming.mak   2017-10-26 20:20:27.317598268 
+0200
--- src/testdir/Make_ming.mak   2017-11-02 20:58:54.169335263 +0100
***
*** 31,37 
  # Omitted:
  # test2   "\\tmp" doesn't work.
  # test10  'errorformat' is different
- # test12  can't unlink a swap file
  # test97  \{ and \$ are not escaped characters
  
  SCRIPTS = $(SCRIPTS_ALL) $(SCRIPTS_MORE1) $(SCRIPTS_MORE4) $(SCRIPTS_WIN32)
--- 31,36 
*** ../vim-8.0.1252/src/testdir/Make_vms.mms2017-10-26 20:20:27.317598268 
+0200
--- src/testdir/Make_vms.mms2017-11-02 20:58:54.169335263 +0100
***
*** 75,87 
 

Re: Patch 8.0.1248

2017-11-02 Fir de Conversatie Dominique Pellé
Bram Moolenaar  wrote:

>
> Patch 8.0.1248 (after 8.0.1247)
> Problem:Stray + in README file.
> Solution:   Remove the +.  Add a line break.
> Files:  README.md


The debian badge was put twice somehow in README.md
Sorry about that. Fixed in attached patch.

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/README.md b/README.md
index 46f3186..41f0875 100644
--- a/README.md
+++ b/README.md
@@ -5,7 +5,7 @@
 [![Coverage Status](https://coveralls.io/repos/vim/vim/badge.svg?branch=master=github)](https://coveralls.io/github/vim/vim?branch=master)
 [![Appveyor Build status](https://ci.appveyor.com/api/projects/status/o2qht2kjm02sgghk?svg=true)](https://ci.appveyor.com/project/chrisbra/vim)
 [![Coverity Scan](https://scan.coverity.com/projects/241/badge.svg)](https://scan.coverity.com/projects/vim)
-[![Debian CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)[![Debian CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)
+[![Debian CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)
 
 
 ## What is Vim? ##


Re: Security risk of vim swap files

2017-11-02 Fir de Conversatie Marvin Renich
* zdoh...@redhat.com  [171102 10:36]:
> can VIm provide a way how to set permissions for swap files? So users
> which consider this VIm behavior as security risk can set permissions
> differently? Would that be possible for VIm (like setting set
> swap_file_perm=775 in vimrc file)?

What security risk do you see?  The original file and swap file are
conceptually treated as one unit.  If someone can do something to the
original (such as writing), preventing that person from writing the swap
file has absolutely no security benefit.

The purpose of umask is to allow a newly created file to have specific
permissions unset at time of creation, preventing a race condition
between file creation and subsequently setting file permissions with
chmod.

With vim and a swap file, using umask to create the swap file with
permissions more restrictive than the original does not prevent anyone
from doing anything he or she can still do with the original.

...Marvin

-- 
-- 
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] Update makefiles in src/po/

2017-11-02 Fir de Conversatie Bram Moolenaar

Ken Takata wrote:

> There are some problems in src/po/Make_*.mak.
> 
> * Make_ming.mak doesn't work well when it is executed on msys2's bash.
> * Some source files are missing from the makefiles.
> 
> Attached patches fix them.

Thanks!

-- 
Men may not be seen publicly in any kind of strapless gown.
[real standing law in Florida, United States of America]

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1252
Problem:Incomplete translations makefile for MinGW/Cygwin.
Solution:   Add missing source files.  Make it work with msys2's bash. (Ken
Takata)
Files:  src/po/Make_cyg.mak, src/po/Make_ming.mak, src/po/Make_mvc.mak


*** ../vim-8.0.1251/src/po/Make_cyg.mak 2015-12-29 16:00:09.0 +0100
--- src/po/Make_cyg.mak 2017-11-02 19:25:52.527382998 +0100
***
*** 128,138 
  
  first_time:
$(XGETTEXT) --default-domain=$(LANGUAGE) \
!   --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) 
../if_perl.xs $(wildcard ../globals.h)
  
  $(LANGUAGES):
$(XGETTEXT) --default-domain=$(PACKAGE) \
!   --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) 
../if_perl.xs $(wildcard ../globals.h)
$(MV) $(PACKAGE).po $(PACKAGE).pot
$(CP) $@.po $@.po.orig
$(MV) $@.po $@.po.old
--- 128,138 
  
  first_time:
$(XGETTEXT) --default-domain=$(LANGUAGE) \
!   --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) 
../if_perl.xs ../GvimExt/gvimext.cpp $(wildcard ../globals.h) ../if_py_both.h
  
  $(LANGUAGES):
$(XGETTEXT) --default-domain=$(PACKAGE) \
!   --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) 
../if_perl.xs ../GvimExt/gvimext.cpp $(wildcard ../globals.h) ../if_py_both.h
$(MV) $(PACKAGE).po $(PACKAGE).pot
$(CP) $@.po $@.po.orig
$(MV) $@.po $@.po.old
*** ../vim-8.0.1251/src/po/Make_ming.mak2015-12-29 16:00:09.0 
+0100
--- src/po/Make_ming.mak2017-11-02 19:25:52.527382998 +0100
***
*** 11,17 
--- 11,21 
  #
  
  ifndef VIMRUNTIME
+ ifeq (sh.exe, $(SHELL))
  VIMRUNTIME = ..\..\runtime
+ else
+ VIMRUNTIME = ../../runtime
+ endif
  endif
  
  LANGUAGES = \
***
*** 100,113 
--- 104,130 
  #GETTEXT_PATH = C:/gettext-0.10.35-w32/win32/Release/
  #GETTEXT_PATH = C:/cygwin/bin/
  
+ ifeq (sh.exe, $(SHELL))
  MSGFMT = set OLD_PO_FILE_INPUT=yes && $(GETTEXT_PATH)msgfmt -v
  XGETTEXT = set OLD_PO_FILE_INPUT=yes && set OLD_PO_FILE_OUTPUT=yes && 
$(GETTEXT_PATH)xgettext
  MSGMERGE = set OLD_PO_FILE_INPUT=yes && set OLD_PO_FILE_OUTPUT=yes && 
$(GETTEXT_PATH)msgmerge
+ else
+ MSGFMT = LANG=C OLD_PO_FILE_INPUT=yes $(GETTEXT_PATH)msgfmt -v
+ XGETTEXT = LANG=C OLD_PO_FILE_INPUT=yes OLD_PO_FILE_OUTPUT=yes 
$(GETTEXT_PATH)xgettext
+ MSGMERGE = LANG=C OLD_PO_FILE_INPUT=yes OLD_PO_FILE_OUTPUT=yes 
$(GETTEXT_PATH)msgmerge
+ endif
  
+ ifeq (sh.exe, $(SHELL))
  MV = move
  CP = copy
  RM = del
  MKD = mkdir
+ else
+ MV = mv -f
+ CP = cp -f
+ RM = rm -f
+ MKD = mkdir -p
+ endif
  
  .SUFFIXES:
  .SUFFIXES: .po .mo .pot
***
*** 120,130 
  
  first_time:
$(XGETTEXT) --default-domain=$(LANGUAGE) \
!   --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) 
../if_perl.xs $(wildcard ../globals.h)
  
  $(LANGUAGES):
$(XGETTEXT) --default-domain=$(PACKAGE) \
!   --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) 
../if_perl.xs $(wildcard ../globals.h)
$(MV) $(PACKAGE).po $(PACKAGE).pot
$(CP) $@.po $@.po.orig
$(MV) $@.po $@.po.old
--- 137,147 
  
  first_time:
$(XGETTEXT) --default-domain=$(LANGUAGE) \
!   --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) 
../if_perl.xs ../GvimExt/gvimext.cpp $(wildcard ../globals.h) ../if_py_both.h
  
  $(LANGUAGES):
$(XGETTEXT) --default-domain=$(PACKAGE) \
!   --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) 
../if_perl.xs ../GvimExt/gvimext.cpp $(wildcard ../globals.h) ../if_py_both.h
$(MV) $(PACKAGE).po $(PACKAGE).pot
$(CP) $@.po $@.po.orig
$(MV) $@.po $@.po.old
***
*** 136,145 
--- 153,170 
$(MKD) $(VIMRUNTIME)\lang\$(LANGUAGE)\LC_MESSAGES
$(CP) $(LANGUAGE).mo 
$(VIMRUNTIME)\lang\$(LANGUAGE)\LC_MESSAGES\$(PACKAGE).mo
  
+ ifeq (sh.exe, $(SHELL))
  install-all: all
FOR %%l IN ($(LANGUAGES)) DO @IF NOT EXIST $(VIMRUNTIME)\lang\%%l 
$(MKD) $(VIMRUNTIME)\lang\%%l
FOR %%l IN ($(LANGUAGES)) DO @IF NOT EXIST 
$(VIMRUNTIME)\lang\%%l\LC_MESSAGES $(MKD) $(VIMRUNTIME)\lang\%%l\LC_MESSAGES
FOR %%l IN ($(LANGUAGES)) DO @$(CP) %%l.mo 
$(VIMRUNTIME)\lang\%%l\LC_MESSAGES\$(PACKAGE).mo
+ else
+ install-all: all
+   for TARGET in $(LANGUAGES); do \
+   $(MKD) $(VIMRUNTIME)/lang/$$TARGET/LC_MESSAGES ; \
+   $(CP) $$TARGET.mo 
$(VIMRUNTIME)/lang/$$TARGET/LC_MESSAGES/$(PACKAGE).mo ; \
+   done
+ endif
  
  clean:
$(RM) *.mo
*** ../vim-8.0.1251/src/po/Make_mvc.mak 2015-12-29 16:00:09.0 +0100
--- src/po/Make_mvc.mak 2017-11-02 19:25:52.531382973 +0100
***
*** 117,123 
  all: $(MOFILES)
  
  files:
!   $(LS) $(LSFLAGS) ..\*.c ..\if_perl.xs ..\globals.h > .\files
  
  first_time: files
set OLD_PO_FILE_INPUT=yes
--- 117,123 
  all: $(MOFILES)
  
  files:
!   

Patch 8.0.1251

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1251 (after 8.0.1249)
Problem:Invalid expressin passed to WaitFor().
Solution:   Check if the variable exists.
Files:  src/testdir/test_clientserver.vim


*** ../vim-8.0.1250/src/testdir/test_clientserver.vim   2017-09-09 
18:10:56.707952547 +0200
--- src/testdir/test_clientserver.vim   2017-11-02 19:21:01.249117090 +0100
***
*** 42,48 
call remote_foreground(name)
  
call remote_send(name, ":let testvar = 'yes'\")
!   call WaitFor('remote_expr("' . name . '", "testvar", "", 1) == "yes"')
call assert_equal('yes', remote_expr(name, "testvar", "", 2))
  
if has('unix') && has('gui') && !has('gui_running')
--- 42,48 
call remote_foreground(name)
  
call remote_send(name, ":let testvar = 'yes'\")
!   call WaitFor('remote_expr("' . name . '", "exists(\"testvar\") ? testvar : 
\"\"", "", 1) == "yes"')
call assert_equal('yes', remote_expr(name, "testvar", "", 2))
  
if has('unix') && has('gui') && !has('gui_running')
*** ../vim-8.0.1250/src/version.c   2017-11-02 19:08:39.741514601 +0100
--- src/version.c   2017-11-02 19:22:25.148619482 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1251,
  /**/

-- 
If an elephant is left tied to a parking meter, the parking fee has to be paid
just as it would for a vehicle.
[real standing law in Florida, United States of America]

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1250
Problem:'hlsearch' highlighting not removed after incsearch (lacygoill)
Solution:   Redraw all windows. Start search at the end of the match.  Improve
how CTRL-G works with incremental search. Add tests. (Christian
Brabandt, Hirohito Higashi, haya14busa, closes #2267)
Files:  runtime/doc/options.txt, src/ex_getln.c,
src/testdir/test_search.vim


*** ../vim-8.0.1249/runtime/doc/options.txt 2017-10-29 16:39:36.258313882 
+0100
--- runtime/doc/options.txt 2017-11-02 18:56:51.217676323 +0100
***
*** 4358,4365 
Example: >
augroup vimrc-incsearch-highlight
  autocmd!
! autocmd CmdlineEnter [/\?] :set hlsearch
! autocmd CmdlineLeave [/\?] :set nohlsearch
augroup END
  <
CTRL-L can be used to add one character from after the current match
--- 4454,4461 
Example: >
augroup vimrc-incsearch-highlight
  autocmd!
! autocmd CmdlineEnter /,\? :set hlsearch
! autocmd CmdlineLeave /,\? :set nohlsearch
augroup END
  <
CTRL-L can be used to add one character from after the current match
*** ../vim-8.0.1249/src/ex_getln.c  2017-10-29 16:39:36.262313855 +0100
--- src/ex_getln.c  2017-11-02 18:56:51.217676323 +0100
***
*** 1717,1728 
--- 1717,1735 
pos_T  t;
intsearch_flags = SEARCH_NOOF;
  
+   if (ccline.cmdlen == 0)
+   goto cmdline_not_changed;
+ 
save_last_search_pattern();
cursor_off();
out_flush();
if (c == Ctrl_G)
{
t = match_end;
+   if (LT_POS(match_start, match_end))
+   /* start searching at the end of the match
+* not at the beginning of the next column */
+   (void)decl();
search_flags += SEARCH_COL;
}
else
***
*** 1945,1950 
--- 1952,1958 
{
i = 0;
SET_NO_HLSEARCH(TRUE); /* turn off previous highlight */
+   redraw_all_later(SOME_VALID);
}
else
{
***
*** 2082,2088 
curwin->w_botline = old_botline;
highlight_match = FALSE;
validate_cursor();  /* needed for TAB */
!   redraw_later(SOME_VALID);
  }
  #endif
  
--- 2090,2096 
curwin->w_botline = old_botline;
highlight_match = FALSE;
validate_cursor();  /* needed for TAB */
!   redraw_all_later(SOME_VALID);
  }
  #endif
  
*** ../vim-8.0.1249/src/testdir/test_search.vim 2017-11-02 16:16:23.286239622 
+0100
--- src/testdir/test_search.vim 2017-11-02 18:56:51.217676323 +0100
***
*** 397,402 
--- 397,513 
bw!
  endfunc
  
+ func Test_search_cmdline6()
+   " Test that consecutive matches
+   " are caught by /
+   if !exists('+incsearch')
+ return
+   endif
+   " need to disable char_avail,
+   " so that expansion of commandline works
+   call test_override("char_avail", 1)
+   new
+   call setline(1, [' bbvimb', ''])
+   set incsearch
+   " first match
+   norm! gg0
+   call feedkeys("/b\", 'tx')
+   call assert_equal([0,1,2,0], getpos('.'))
+   " second match
+   norm! gg0
+   call feedkeys("/b\\", 'tx')
+   call assert_equal([0,1,3,0], getpos('.'))
+   " third match
+   norm! gg0
+   call feedkeys("/b\\\", 'tx')
+   call assert_equal([0,1,7,0], getpos('.'))
+   " first match again
+   norm! gg0
+   call feedkeys("/b", 'tx')
+   call assert_equal([0,1,2,0], getpos('.'))
+   set nowrapscan
+   " last match
+   norm! gg0
+   call feedkeys("/b", 'tx')
+   call assert_equal([0,1,7,0], getpos('.'))
+   " clean up
+   set wrapscan
+   set noincsearch
+   call test_override("char_avail", 0)
+   bw!
+ endfunc
+ 
+ func Test_search_cmdline7()
+   " Test that an pressing  in an empty command line
+   " does not move the cursor
+   if !exists('+incsearch')
+ return
+   endif
+   " need to disable char_avail,
+   " so that expansion of commandline works
+   call test_override("char_avail", 1)
+   new
+   let @/='b'
+   call setline(1, [' bbvimb', ''])
+   set incsearch
+   " first match
+   norm! gg0
+   " moves to next match of previous search pattern, just like /
+   call feedkeys("/\\", 'tx')
+   call assert_equal([0,1,2,0], getpos('.'))
+   " moves to next match of previous search pattern, just like /
+   call feedkeys("/\", 'tx')
+   call assert_equal([0,1,3,0], getpos('.'))
+   " moves to next match of previous search pattern, just like /
+   call feedkeys("/\\", 'tx')
+   call assert_equal([0,1,7,0], getpos('.'))
+   set noincsearch
+   call test_override("char_avail", 0)
+   

Re: [patch] added debian build badge

2017-11-02 Fir de Conversatie Matěj Cepl
On 2017-11-02, 11:16 GMT, Dominique Pellé wrote:
> For Fedora, I see this link:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=992971
> … but it only seems to have compilation logs, not test logs
> which it less useful than the debian page.

Testsuite is not run while building Fedora/RHEL packages 
apparently.

I have run vim8-1245 locally on RHEL_7/x86_64 and the logs are 
https://mcepl.fedorapeople.org/tmp/vim-1245-check-logs.zip

Also, I run the same src.rpm package here 
https://copr.fedorainfracloud.org/coprs/build/657132/

Best,

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
It is the mark of an educated mind to be able to entertain
a thought without accepting it.
  -- Aristotle

-- 
-- 
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] added debian build badge

2017-11-02 Fir de Conversatie Matěj Cepl
On 2017-11-02, 11:16 GMT, Dominique Pellé wrote:
> For Fedora, I see this link:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=992971
> ... but it only seems to have compilation logs, not test logs
> which it less useful than the debian page.

I can also do build on the internal systems (I have easily ppc, 
x86_64, s390, aarch64, ppc64le, ppc64, i686, and s390x 
available), unfortunately they are not available from outside.  
I can put logs somewhere.

Best,

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
He loves nature in spite of what it did to him.
  -- Forrest Tucker

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1249
Problem:No error when WaitFor() gets an invalid wrong expression.
Solution:   Do not ignore errors in evaluationg the expression.  Fix places
where the expression was wrong.
Files:  src/testdir/shared.vim, src/testdir/test_netbeans.vim


*** ../vim-8.0.1248/src/testdir/shared.vim  2017-11-02 16:57:54.375496815 
+0100
--- src/testdir/shared.vim  2017-11-02 18:18:27.755170149 +0100
***
*** 125,139 
  let slept = 0
endif
for i in range(timeout / 10)
! try
!   if eval(a:expr)
!   if has('reltime')
! return float2nr(reltimefloat(reltime(start)) * 1000)
!   endif
!   return slept
endif
! catch
! endtry
  if !has('reltime')
let slept += 10
  endif
--- 125,136 
  let slept = 0
endif
for i in range(timeout / 10)
! if eval(a:expr)
!   if has('reltime')
!   return float2nr(reltimefloat(reltime(start)) * 1000)
endif
!   return slept
! endif
  if !has('reltime')
let slept += 10
  endif
*** ../vim-8.0.1248/src/testdir/test_netbeans.vim   2017-11-02 
16:57:54.379496792 +0100
--- src/testdir/test_netbeans.vim   2017-11-02 17:59:12.965952884 +0100
***
*** 19,24 
--- 19,25 
  
  func Nb_basic(port)
call delete("Xnetbeans")
+   call writefile([], "Xnetbeans")
exe 'nbstart :localhost:' . a:port . ':bunny'
call assert_true(has("netbeans_enabled"))
  
***
*** 53,58 
--- 54,62 
  endfunc
  
  func Nb_file_auth(port)
+   call delete("Xnetbeans")
+   call writefile([], "Xnetbeans")
+ 
call assert_fails('nbstart =notexist', 'E660:')
call writefile(['host=localhost', 'port=' . a:port, 'auth=bunny'], 
'Xnbauth')
if has('unix')
*** ../vim-8.0.1248/src/version.c   2017-11-02 18:12:56.097119507 +0100
--- src/version.c   2017-11-02 18:19:02.962963112 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1249,
  /**/

-- 
You can be stopped by the police for biking over 65 miles per hour.
You are not allowed to walk across a street on your hands.
[real standing laws in Connecticut, United States of America]

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1248 (after 8.0.1247)
Problem:Stray + in README file.
Solution:   Remove the +.  Add a line break.
Files:  README.md


*** ../vim-8.0.1247/README.md   2017-11-02 18:09:55.898177904 +0100
--- README.md   2017-11-02 18:11:31.889614167 +0100
***
*** 1,10 
  `README.md` for version 8.0 of Vim: Vi IMproved.
  [![Build 
Status](https://travis-ci.org/vim/vim.svg?branch=master)](https://travis-ci.org/vim/vim)
  [![Coverage 
Status](https://codecov.io/gh/vim/vim/coverage.svg?branch=master)](https://codecov.io/gh/vim/vim?branch=master)
  [![Coverage 
Status](https://coveralls.io/repos/vim/vim/badge.svg?branch=master=github)](https://coveralls.io/github/vim/vim?branch=master)
  [![Appveyor Build 
status](https://ci.appveyor.com/api/projects/status/o2qht2kjm02sgghk?svg=true)](https://ci.appveyor.com/project/chrisbra/vim)
  [![Coverity 
Scan](https://scan.coverity.com/projects/241/badge.svg)](https://scan.coverity.com/projects/vim)
! +[![Debian 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)[![Debian
 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)
  
  
  ## What is Vim? ##
--- 1,11 
  `README.md` for version 8.0 of Vim: Vi IMproved.
+ 
  [![Build 
Status](https://travis-ci.org/vim/vim.svg?branch=master)](https://travis-ci.org/vim/vim)
  [![Coverage 
Status](https://codecov.io/gh/vim/vim/coverage.svg?branch=master)](https://codecov.io/gh/vim/vim?branch=master)
  [![Coverage 
Status](https://coveralls.io/repos/vim/vim/badge.svg?branch=master=github)](https://coveralls.io/github/vim/vim?branch=master)
  [![Appveyor Build 
status](https://ci.appveyor.com/api/projects/status/o2qht2kjm02sgghk?svg=true)](https://ci.appveyor.com/project/chrisbra/vim)
  [![Coverity 
Scan](https://scan.coverity.com/projects/241/badge.svg)](https://scan.coverity.com/projects/vim)
! [![Debian 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)[![Debian
 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)
  
  
  ## What is Vim? ##
*** ../vim-8.0.1247/src/version.c   2017-11-02 18:09:55.898177904 +0100
--- src/version.c   2017-11-02 18:12:21.589322230 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1248,
  /**/

-- 
It is illegal for anyone to try and stop a child from playfully jumping over
puddles of water.
[real standing law in California, United States of America]

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1247
Problem:Not easy to find Debian build info.
Solution:   Add a badge in the README file. (Dominique Pelle)
Files:  README.md


*** ../vim-8.0.1246/README.md   2017-03-25 18:10:26.867248943 +0100
--- README.md   2017-11-02 18:07:28.403043806 +0100
***
*** 4,9 
--- 4,10 
  [![Coverage 
Status](https://coveralls.io/repos/vim/vim/badge.svg?branch=master=github)](https://coveralls.io/github/vim/vim?branch=master)
  [![Appveyor Build 
status](https://ci.appveyor.com/api/projects/status/o2qht2kjm02sgghk?svg=true)](https://ci.appveyor.com/project/chrisbra/vim)
  [![Coverity 
Scan](https://scan.coverity.com/projects/241/badge.svg)](https://scan.coverity.com/projects/vim)
+ +[![Debian 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)[![Debian
 
CI](https://badges.debian.net/badges/debian/testing/vim/version.svg)](https://buildd.debian.org/vim)
  
  
  ## What is Vim? ##
*** ../vim-8.0.1246/src/version.c   2017-11-02 17:50:09.901161926 +0100
--- src/version.c   2017-11-02 18:08:26.778701145 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1247,
  /**/

-- 
It is illegal for a driver to be blindfolded while operating a vehicle.
[real standing law in Alabama, United States of America]

 /// 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] added debian build badge

2017-11-02 Fir de Conversatie Bram Moolenaar

Dominique wrote:

> I see that the neovim github page has a
> debian CI badge. See:
> https://github.com/neovim/neovim
> 
> How about adding a similar badge in the vim
> github page?  I attach a patch to do that (not tested)
> which links to:
> https://buildd.debian.org/status/package.php?p=vim
> 
> Debian builds on many platforms which is useful
> to have a look at. It's currently using vim-8.0.1226.
> Glancing at those builds logs, I see:
> 
> - failures in Test_popup_and_window_resize() on at least mips
>   hppa, and sparc64 platforms, which are presumably fixed
>   in vim-8.0.1241
> 
> - failures in Test_terminal_composing_unicode() and
>   Test_terminal_special_chars() on hppa platform, See:
>   
> https://buildd.debian.org/status/fetch.php?pkg=vim=hppa=2%3A8.0.1226-1=1509125272=0
> 
> - segfault in Test_finish_open_close() on hurd-386 platform.
>   See: 
> https://buildd.debian.org/status/fetch.php?pkg=vim=hurd-i386=2%3A8.0.1226-1=1509286549=0
> 
> - segfault on alpha platform. See:
>   
> https://buildd.debian.org/status/fetch.php?pkg=vim=alpha=2%3A8.0.1226-1=1509205720=0
> 
> Unfortunately, I see no stack trace when there is a
> segfault so I don't know how we can investigate crashes
> on hurd-386 and alphan platforms.

Thanks.  Makes it easy to find this info.  It's up to the reader what to
do with it, it's quite overwhelming.

-- 
There is no right or wrong, there is only your personal opinion.
 (Bram Moolenaar)

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1246
Problem:Popup test has an arbitrary delay.
Solution:   Wait for the ruler to show. (James McCoy)
Files:  src/testdir/test_popup.vim


*** ../vim-8.0.1245/src/testdir/test_popup.vim  2017-10-31 22:19:54.732086180 
+0100
--- src/testdir/test_popup.vim  2017-11-02 17:40:11.560690990 +0100
***
*** 637,645 
if h < 15
  return
endif
!   let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile'], 
{'term_rows': h / 3})
!   call term_sendkeys(g:buf, (h / 3 - 1)."o\")
!   call term_wait(g:buf, 500)
call term_sendkeys(g:buf, "Gi\")
call term_sendkeys(g:buf, "\")
call term_wait(g:buf, 100)
--- 637,649 
if h < 15
  return
endif
!   let rows = h / 3
!   let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile'], 
{'term_rows': rows})
!   call term_sendkeys(g:buf, (h / 3 - 1) . "o\")
!   " Wait for the nested Vim to exit insert mode, where it will show the ruler.
!   " Need to trigger a redraw.
!   call WaitFor(printf('execute("redraw") == "" && term_getline(g:buf, %d) =~ 
"\\<%d,.*Bot"', rows, rows))
! 
call term_sendkeys(g:buf, "Gi\")
call term_sendkeys(g:buf, "\")
call term_wait(g:buf, 100)
*** ../vim-8.0.1245/src/version.c   2017-11-02 16:57:54.379496792 +0100
--- src/version.c   2017-11-02 17:48:57.753587844 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1246,
  /**/

-- 
Every person is responsible for the choices he makes.

 /// 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: Security risk of vim swap files

2017-11-02 Fir de Conversatie Christian Brabandt

On Mi, 01 Nov 2017, Ken Takata wrote:

> This makes Vim to respect umask when creating a swapfile.
> (I'm not sure this is actually needed, though.)

I am also not sure if this is needed. However it makes sense to have the 
swap file with the same permissions of the original file. Think of a 
crash of an editing session of a file that has o+rw set. In that case 
and with a restrictive umask of 0077 only the author could restore it, 
while currently everybody who is allowed to edit that file can also 
recover it.


Christian
-- 
Es kann so schön sein, alt zu werden, das Gefühl zu haben, das fast 
schon ein Glück ist, mehr von jenen Dingen zu wissen, an die man
früher nicht einmal gedacht hat. Weil man angeblich keine Zeit hatte.
-- Heinz Rühmann

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

2017-11-02 Fir de Conversatie Bram Moolenaar

James McCoy wrote:

> On Wed, Nov 01, 2017 at 09:22:45PM +0100, Bram Moolenaar wrote:
> > That's defenitely better than an arbitrary delay.  However, I think your
> > check just never matches and causes a delay of one second.
> 
> That's surprising that WaitFor() silently fails, but you are right.

Yeah, the idea is that that caller checks the returned value, but in
practice that never happens.  It's better to throw an exception on
timeout.  When I do that I find several places where the expression is
wrong.

> I tested this patch and it does work:
> > 
> > diff --git i/src/testdir/test_popup.vim w/src/testdir/test_popup.vim
> > index 2781aabcd..0746efc7f 100644
> > --- i/src/testdir/test_popup.vim
> > +++ w/src/testdir/test_popup.vim
> > @@ -637,9 +637,11 @@ func Test_popup_and_window_resize()
> >if h < 15
> >  return
> >endif
> > -  let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set 
> > noswapfile'], {'term_rows': h / 3})
> > +  let rows = h / 3
> > +  let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set 
> > noswapfile'], {'term_rows': rows})
> >call term_sendkeys(g:buf, (h / 3 - 1)."o\")
> > -  call term_wait(g:buf, 500)
> > +  " Wait for the nested Vim to exit insert mode, where it will show the 
> > ruler
> > +  call WaitFor(printf('term_getline(g:buf, %d) =~ "\<%d,.*Bot"', rows, 
> > rows))
> >call term_sendkeys(g:buf, "Gi\")
> >call term_sendkeys(g:buf, "\")
> >call term_wait(g:buf, 100)

Now that WaitFor() throws an error I see this doesn't work.  At least an
explicit redraw appears to be needed.

Ah, the backslash needs to be doubled.

-- 
Every exit is an entrance into something else.

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

2017-11-02 Fir de Conversatie Christian Brabandt

On Do, 02 Nov 2017, Bram Moolenaar wrote:

> 
> Christian Brabandt wrote:
> 
> > On Di, 31 Okt 2017, Christian Brabandt wrote:
> > 
> > > 
> > > On So, 29 Okt 2017, Bram Moolenaar wrote:
> > > 
> > > > Patch 8.0.1238
> > > > Problem:Incremental search only shows one match.
> > > > Solution:   When 'incsearch' and and 'hlsearch' are both set highlight 
> > > > all
> > > > matches. (haya14busa, closes #2198)
> > > > Files:  runtime/doc/options.txt, src/ex_getln.c, 
> > > > src/proto/search.pro,
> > > > src/search.c, src/testdir/test_search.vim
> > > 
> > > It looks like the test does not work correctly on Windows. I see some 
> > > failures:
> > > https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/job/g4p49k5gh6k3nbq5
> > > ,
> > > | From test_search.vim:
> > > | Found errors in Test_search_cmdline_incsearch_highlight_attr(): 
> > > function RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr 
> > > | line 28: Expected not equal to 292 function 
> > > RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr 
> > > | line 29: Expected not equal to 292 function 
> > > RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr 
> > > | line 30: Expected not equal to 292
> > > | TEST FAILURE NMAKE : fatal error U1077: 'if' : return code '0x1'
> > > `
> > > 
> > > This test is now disabled for the vim-win32-installer build. Once it 
> > > builds again, I'll try to debug this test.
> > 
> > I debugged it a bit further. I think the problem is this line:
> > ,
> > |  call term_sendkeys(g:buf, 'i' . join(lines, "\n") . "\gg0")
> > `
> > 
> > Sending "\" does not work. Instead it looks like it sends meta/alt 
> > key, e.g. it set's the high bit of the following character and therefore 
> > does never exit insert mode.
> 
> Strange, is this not using the normal termcap perhaps?

on Windows? Isn't that a unix thing?


Christian
-- 
Die Welt zerfällt in die, die das Unglaubliche glauben, und die die
das Unwahrscheinliche tun.
-- Lord Illingworth

-- 
-- 
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] added debian build badge

2017-11-02 Fir de Conversatie Matěj Cepl
On 2017-11-02, 11:16 GMT, Dominique Pellé wrote:
> I don't think it's silly. It helps to find bugs in Vim on 
> platforms that are rarely used. I was not aware of vim crashes 
> on alpha or hurd x86 until I saw those debian test logs of 
> vim-8.0.1241.  If someone has the time they could be 
> investigated. We should be able to run hurd with QEMU for 
> example. 

For that you should have maintainers on these platforms, 
centralization in one place doesn’t scale. Karsten Hopp just 
have been doing too fine job of maintaining vim on Fedora/RHEL 
to be ignored.

> For Fedora, I see this link:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=992971
> ... but it only seems to have compilation logs, not test logs
> which it less useful than the debian page.

Yeah, we don’t seem to run make check during the build, all 
testing would be in that one log if we did.

How to run a testsuite? Do you need to do something with 
./configure or it just running ``make check``? I can switch that 
on in my COPR on 
https://copr.fedorainfracloud.org/coprs/mcepl/vim8/

Best,

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
If you have a problem and you think awk(1) is the solution, then
you have two problems.
   -- David Tilbrook (at least 1989, source of the later famous
  jwz rant on regular expressions).

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1245
Problem:When WaitFor() has a wrong expression it just waits a second,
which goes unnoticed. (James McCoy)
Solution:   When WaitFor() times out throw an exception.  Fix places where the
expression was wrong.
Files:  src/testdir/shared.vim, src/testdir/test_channel.vim,
src/testdir/test_netbeans.vim, src/testdir/test_terminal.vim


*** ../vim-8.0.1244/src/testdir/shared.vim  2017-10-07 20:03:19.323835305 
+0200
--- src/testdir/shared.vim  2017-11-02 16:24:57.703180540 +0100
***
*** 139,145 
  endif
  sleep 10m
endfor
!   return timeout
  endfunc
  
  " Wait for up to a given milliseconds.
--- 139,145 
  endif
  sleep 10m
endfor
!   throw 'WaitFor() timed out after ' . timeout . ' msec'
  endfunc
  
  " Wait for up to a given milliseconds.
*** ../vim-8.0.1244/src/testdir/test_channel.vim2017-10-06 
01:07:32.056360695 +0200
--- src/testdir/test_channel.vim2017-11-02 16:50:08.030199053 +0100
***
*** 709,715 
  call ch_sendraw(handle, "double this\n")
  call ch_sendraw(handle, "quit\n")
  sp pipe-output
! call WaitFor('line("$") >= 6 && g:Ch_bufClosed == "yes"')
  call assert_equal(expected, getline(1, '$'))
  if a:nomod
call assert_equal(0, )
--- 709,715 
  call ch_sendraw(handle, "double this\n")
  call ch_sendraw(handle, "quit\n")
  sp pipe-output
! call WaitFor('line("$") == ' . len(expected) . ' && g:Ch_bufClosed == 
"yes"')
  call assert_equal(expected, getline(1, '$'))
  if a:nomod
call assert_equal(0, )
***
*** 804,810 
  call ch_sendraw(handle, "doubleerr this\n")
  call ch_sendraw(handle, "quit\n")
  sp pipe-err
! call WaitFor('line("$") >= 5')
  call assert_equal(expected, getline(1, '$'))
  if a:nomod
call assert_equal(0, )
--- 804,810 
  call ch_sendraw(handle, "doubleerr this\n")
  call ch_sendraw(handle, "quit\n")
  sp pipe-err
! call WaitFor('line("$") == ' . len(expected))
  call assert_equal(expected, getline(1, '$'))
  if a:nomod
call assert_equal(0, )
***
*** 1130,1141 
let job = job_start([s:python, '-c', 
  \ 'import sys; [sys.stdout.write(".") and sys.stdout.flush() for _ in 
range(1)]'], options)
call assert_equal("run", job_status(job))
!   call WaitFor('len(join(getline(2,line("$")),"") >= 1')
try
! for line in getline(2, '$')
!   let line = substitute(line, '^\.*', '', '')
!   call assert_equal('', line)
  endfor
finally
  call job_stop(job)
  bwipe!
--- 1130,1143 
let job = job_start([s:python, '-c', 
  \ 'import sys; [sys.stdout.write(".") and sys.stdout.flush() for _ in 
range(1)]'], options)
call assert_equal("run", job_status(job))
!   call WaitFor('len(join(getline(1, "$"), "")) >= 1', 3000)
try
! let totlen = 0
! for line in getline(1, '$')
!   call assert_equal('', substitute(line, '^\.*', '', ''))
!   let totlen += len(line)
  endfor
+ call assert_equal(1, totlen)
finally
  call job_stop(job)
  bwipe!
***
*** 1300,1323 
endif
call ch_log('Test_close_and_exit_cb')
  
!   let dict = {'ret': {}}
!   func dict.close_cb(ch) dict
  let self.ret['close_cb'] = job_status(ch_getjob(a:ch))
endfunc
!   func dict.exit_cb(job, status) dict
  let self.ret['exit_cb'] = job_status(a:job)
endfunc
  
let g:job = job_start('echo', {
! \ 'close_cb': dict.close_cb,
! \ 'exit_cb': dict.exit_cb,
  \ })
call assert_equal('run', job_status(g:job))
unlet g:job
!   call WaitFor('len(dict.ret) >= 2')
!   call assert_equal(2, len(dict.ret))
!   call assert_match('^\%(dead\|run\)', dict.ret['close_cb'])
!   call assert_equal('dead', dict.ret['exit_cb'])
  endfunc
  
  ""
--- 1302,1326 
endif
call ch_log('Test_close_and_exit_cb')
  
!   let g:retdict = {'ret': {}}
!   func g:retdict.close_cb(ch) dict
  let self.ret['close_cb'] = job_status(ch_getjob(a:ch))
endfunc
!   func g:retdict.exit_cb(job, status) dict
  let self.ret['exit_cb'] = job_status(a:job)
endfunc
  
let g:job = job_start('echo', {
! \ 'close_cb': g:retdict.close_cb,
! \ 'exit_cb': g:retdict.exit_cb,
  \ })
call assert_equal('run', job_status(g:job))
unlet g:job
!   call WaitFor('len(g:retdict.ret) >= 2')
!   call assert_equal(2, len(g:retdict.ret))
!   call assert_match('^\%(dead\|run\)', g:retdict.ret['close_cb'])
!   call assert_equal('dead', g:retdict.ret['exit_cb'])
!   unlet g:retdict
  endfunc
  
  ""
***
*** 1547,1559 
  return
endif
  
!   let job = job_start([s:python, '-c', 'import time;time.sleep(10)'])
try
! call job_stop(job)
! call WaitFor('"dead" == job_status(job)')
! call assert_equal('dead', 

Re: Patch 8.0.1238

2017-11-02 Fir de Conversatie Bram Moolenaar

Christian Brabandt wrote:

> On Di, 31 Okt 2017, Christian Brabandt wrote:
> 
> > 
> > On So, 29 Okt 2017, Bram Moolenaar wrote:
> > 
> > > Patch 8.0.1238
> > > Problem:Incremental search only shows one match.
> > > Solution:   When 'incsearch' and and 'hlsearch' are both set highlight all
> > > matches. (haya14busa, closes #2198)
> > > Files:  runtime/doc/options.txt, src/ex_getln.c, src/proto/search.pro,
> > > src/search.c, src/testdir/test_search.vim
> > 
> > It looks like the test does not work correctly on Windows. I see some 
> > failures:
> > https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/job/g4p49k5gh6k3nbq5
> > ,
> > | From test_search.vim:
> > | Found errors in Test_search_cmdline_incsearch_highlight_attr(): function 
> > RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr 
> > | line 28: Expected not equal to 292 function 
> > RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr 
> > | line 29: Expected not equal to 292 function 
> > RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr 
> > | line 30: Expected not equal to 292
> > | TEST FAILURE NMAKE : fatal error U1077: 'if' : return code '0x1'
> > `
> > 
> > This test is now disabled for the vim-win32-installer build. Once it 
> > builds again, I'll try to debug this test.
> 
> I debugged it a bit further. I think the problem is this line:
> ,
> |  call term_sendkeys(g:buf, 'i' . join(lines, "\n") . "\gg0")
> `
> 
> Sending "\" does not work. Instead it looks like it sends meta/alt 
> key, e.g. it set's the high bit of the following character and therefore 
> does never exit insert mode.

Strange, is this not using the normal termcap perhaps?

> I don't know why this is so here is a patch, that uses a temp file as a 
> workaround.

Thanks.  I'll change the first term_wait() into WaitFor(), that's more
reliable.


-- 
SIGFUN -- signature too funny (core dumped)

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1244
Problem:Search test does not work correctly on MS-Windows.
Solution:   Put text in a file instead of sending it to the terminal.
(Christian Brabandt)
Files:  src/testdir/test_search.vim


*** ../vim-8.0.1243/src/testdir/test_search.vim 2017-11-02 15:59:53.132217481 
+0100
--- src/testdir/test_search.vim 2017-11-02 16:09:20.280757747 +0100
***
*** 494,506 
if h < 3
  return
endif
-   let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile'], 
{'term_rows': 3})
  
" Prepare buffer text
!   let lines = ['abb vim vim vi', 'vimvivim']
!   call term_sendkeys(g:buf, 'i' . join(lines, "\n") . "\gg0")
!   call term_wait(g:buf, 200)
!   call assert_equal(lines[0], term_getline(g:buf, 1))
  
" Get attr of normal(a0), incsearch(a1), hlsearch(a2) highlight
call term_sendkeys(g:buf, ":set incsearch hlsearch\")
--- 494,508 
if h < 3
  return
endif
  
" Prepare buffer text
!   let g:lines = ['abb vim vim vi', 'vimvivim']
!   call writefile(g:lines, 'Xsearch.txt')
!   let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile', 
'Xsearch.txt'], {'term_rows': 3})
!   call WaitFor('g:lines[0] == term_getline(g:buf, 1)')
!   call assert_equal(g:lines[0], term_getline(g:buf, 1))
!   call assert_equal(g:lines[1], term_getline(g:buf, 2))
!   unlet g:lines
  
" Get attr of normal(a0), incsearch(a1), hlsearch(a2) highlight
call term_sendkeys(g:buf, ":set incsearch hlsearch\")
***
*** 565,570 
--- 567,573 
call assert_equal(attr_line1, map(term_scrape(g:buf, 
1)[:len(attr_line1)-1], 'v:val.attr'))
call assert_equal(attr_line2, map(term_scrape(g:buf, 
2)[:len(attr_line2)-1], 'v:val.attr'))
  
+   call delete('Xsearch.txt')
bwipe!
  endfunc
  
*** ../vim-8.0.1243/src/version.c   2017-11-02 15:59:53.132217481 +0100
--- src/version.c   2017-11-02 16:11:34.867950372 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1244,
  /**/

-- 
BRIDGEKEEPER: What is the air-speed velocity of an unladen swallow?
ARTHUR:   What do you mean?  An African or European swallow?
BRIDGEKEEPER: Er ...  I don't know that ... Arrggghhh!
   BRIDGEKEEPER is cast into the gorge.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

2017-11-02 Fir de Conversatie Christian Brabandt

On Do, 02 Nov 2017, Bram Moolenaar wrote:

> 
> Christian Brabandt wrote:
> 
> > On So, 29 Okt 2017, Christian Brabandt wrote:
> > 
> > > On Sa, 28 Okt 2017, Bram Moolenaar wrote:
> > > > Feel free to make one.  
> > > 
> > > I kind of knew that this answer would come :)
> > > 
> > > Okay, will look into that one and the other undefined behaviour patches.
> > > 
> > > > I can't reproduce the error.
> > > 
> > > I was thinking, it would still make sense to have them as test, even if 
> > > those don't trigger the error in every environment.
> > 
> > 
> > Okay, how about this patch:
> > 
> > diff --git a/src/testdir/test_normal.vim b/src/testdir/test_normal.vim
> > index f6b1a43b8..7d31373c9 100644
> > --- a/src/testdir/test_normal.vim
> > +++ b/src/testdir/test_normal.vim
> > @@ -1208,6 +1208,13 @@ func! Test_normal19_z_spell()
> >call assert_match("Word 'goood' added to ./Xspellfile2.add", a)
> >call assert_equal('goood', cnt[0])
> > 
> > +  " Test for :spellgood!
> > +  let temp=execute(':spe!0/0')
> > +  call assert_match('Invalid region', temp)
> > +  let spellfile=matchstr(temp, 'Invalid region nr in \zs.*\ze line \d: 0')
> > +  call assert_equal(['# goood', '# goood/!', '#oood', '0/0'], 
> > readfile(spellfile))
> > +  call delete(spellfile)
> > +
> >" clean up
> >exe "lang" oldlang
> >call delete("./Xspellfile.add")
> > diff --git a/src/testdir/test_search.vim b/src/testdir/test_search.vim
> > index b863fcbba..9e3b8783c 100644
> > --- a/src/testdir/test_search.vim
> > +++ b/src/testdir/test_search.vim
> > @@ -567,3 +567,22 @@ func Test_search_cmdline_incsearch_highlight_attr()
> > 
> >bwipe!
> >  endfunc
> > +
> > +func Test_search_undefined_behaviour()
> > +  if !has("terminal")
> > +return
> > +  endif
> > +  let h = winheight(0)
> > +  if h < 3
> > +return
> > +  endif
> > +  " did cause an undefined left shift
> > +  let g:buf = term_start([GetVimProg(), '--clean', '-e', '-s', '-c', 'call 
> > search(getline("."))', 'samples/test000'], {'term_rows': 3})
> > +  call assert_equal([''], getline(1, '$'))
> > +  call term_sendkeys(g:buf, ":qa!\")
> > +  bwipe!
> > +endfunc
> > +
> > +func Test_search_undefined_behaviour2()
> > +  call assert_fails("call search('\\%UC000')", 'E486')
> > +endfu
> > 
> > This already includes a test for issue #2255, that currently fails.
> 
> Thanks.  I'll eave out the failing part.

Note, it needs the samples/test000 file from the referenced issue.

Christian
-- 
Strasser:  Welche Nationalität haben Sie?
Rick:  Ich bin Trinker.
Renault:   Und damit ist er Weltbürger!
  (aus "Casablanca")

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1243
Problem:No test for what 8.0.1227 fixes.
Solution:   Add a test that triggers the problem. (Christian Brabandt)
Files:  src/testdir/test_normal.vim, src/testdir/test_search.vim


*** ../vim-8.0.1242/src/testdir/test_normal.vim 2017-10-15 22:07:35.211683156 
+0200
--- src/testdir/test_normal.vim 2017-11-02 15:59:42.764280726 +0100
***
*** 1208,1213 
--- 1208,1220 
call assert_match("Word 'goood' added to ./Xspellfile2.add", a)
call assert_equal('goood', cnt[0])
  
+   " Test for :spellgood!
+   let temp = execute(':spe!0/0')
+   call assert_match('Invalid region', temp)
+   let spellfile = matchstr(temp, 'Invalid region nr in \zs.*\ze line \d: 0')
+   call assert_equal(['# goood', '# goood/!', '#oood', '0/0'], 
readfile(spellfile))
+   call delete(spellfile)
+ 
" clean up
exe "lang" oldlang
call delete("./Xspellfile.add")
*** ../vim-8.0.1242/src/testdir/test_search.vim 2017-10-30 21:48:36.482732724 
+0100
--- src/testdir/test_search.vim 2017-11-02 15:57:04.761240907 +0100
***
*** 567,569 
--- 567,584 
  
bwipe!
  endfunc
+ 
+ func Test_search_undefined_behaviour()
+   if !has("terminal")
+ return
+   endif
+   let h = winheight(0)
+   if h < 3
+ return
+   endif
+   " did cause an undefined left shift
+   let g:buf = term_start([GetVimProg(), '--clean', '-e', '-s', '-c', 'call 
search(getline("."))', 'samples/test000'], {'term_rows': 3})
+   call assert_equal([''], getline(1, '$'))
+   call term_sendkeys(g:buf, ":qa!\")
+   bwipe!
+ endfunc
*** ../vim-8.0.1242/src/version.c   2017-11-02 15:44:07.917903684 +0100
--- src/version.c   2017-11-02 15:46:51.164925137 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1243,
  /**/

-- 
Q: What kind of stuff do you do?
A: I collect hobbies.

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Christian Brabandt wrote:

> On So, 29 Okt 2017, Christian Brabandt wrote:
> 
> > On Sa, 28 Okt 2017, Bram Moolenaar wrote:
> > > Feel free to make one.  
> > 
> > I kind of knew that this answer would come :)
> > 
> > Okay, will look into that one and the other undefined behaviour patches.
> > 
> > > I can't reproduce the error.
> > 
> > I was thinking, it would still make sense to have them as test, even if 
> > those don't trigger the error in every environment.
> 
> 
> Okay, how about this patch:
> 
> diff --git a/src/testdir/test_normal.vim b/src/testdir/test_normal.vim
> index f6b1a43b8..7d31373c9 100644
> --- a/src/testdir/test_normal.vim
> +++ b/src/testdir/test_normal.vim
> @@ -1208,6 +1208,13 @@ func! Test_normal19_z_spell()
>call assert_match("Word 'goood' added to ./Xspellfile2.add", a)
>call assert_equal('goood', cnt[0])
> 
> +  " Test for :spellgood!
> +  let temp=execute(':spe!0/0')
> +  call assert_match('Invalid region', temp)
> +  let spellfile=matchstr(temp, 'Invalid region nr in \zs.*\ze line \d: 0')
> +  call assert_equal(['# goood', '# goood/!', '#oood', '0/0'], 
> readfile(spellfile))
> +  call delete(spellfile)
> +
>" clean up
>exe "lang" oldlang
>call delete("./Xspellfile.add")
> diff --git a/src/testdir/test_search.vim b/src/testdir/test_search.vim
> index b863fcbba..9e3b8783c 100644
> --- a/src/testdir/test_search.vim
> +++ b/src/testdir/test_search.vim
> @@ -567,3 +567,22 @@ func Test_search_cmdline_incsearch_highlight_attr()
> 
>bwipe!
>  endfunc
> +
> +func Test_search_undefined_behaviour()
> +  if !has("terminal")
> +return
> +  endif
> +  let h = winheight(0)
> +  if h < 3
> +return
> +  endif
> +  " did cause an undefined left shift
> +  let g:buf = term_start([GetVimProg(), '--clean', '-e', '-s', '-c', 'call 
> search(getline("."))', 'samples/test000'], {'term_rows': 3})
> +  call assert_equal([''], getline(1, '$'))
> +  call term_sendkeys(g:buf, ":qa!\")
> +  bwipe!
> +endfunc
> +
> +func Test_search_undefined_behaviour2()
> +  call assert_fails("call search('\\%UC000')", 'E486')
> +endfu
> 
> This already includes a test for issue #2255, that currently fails.

Thanks.  I'll eave out the failing part.

-- 
Q: Why does /dev/null accept only integers?
A: You can't sink a float.

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

2017-11-02 Fir de Conversatie Bram Moolenaar

Patch 8.0.1242
Problem:Function argument with only dash is seen as number zero. (Wang
Shidong)
Solution:   See a dash as a string. (Christian Brabandt)
Files:  src/testdir/test_ins_complete.vim, src/Makefile, src/eval.c


*** ../vim-8.0.1241/src/testdir/test_ins_complete.vim   2017-10-27 
00:54:59.146125099 +0200
--- src/testdir/test_ins_complete.vim   2017-11-02 15:31:38.742384431 +0100
***
*** 90,92 
--- 90,111 
call delete('Xtestdata')
set cpt& cot& def& tags& tagbsearch& hidden&
  endfunc
+ 
+ func Test_omni_dash()
+   func Omni(findstart, base)
+ if a:findstart
+ return 5
+ else
+ echom a:base
+   return ['-help', '-v']
+ endif
+   endfunc
+   set omnifunc=Omni
+   new
+   exe "normal Gofind -\\"
+   call assert_equal("\n-\nmatch 1 of 2", execute(':2mess'))
+ 
+   bwipe!
+   delfunc Omni
+   set omnifunc=
+ endfunc
*** ../vim-8.0.1241/src/Makefile2017-10-29 15:26:39.212867448 +0100
--- src/Makefile2017-11-02 15:28:01.475680518 +0100
***
*** 2189,2194 
--- 2189,2195 
test_hlsearch \
test_increment \
test_increment_dbcs \
+   test_ins_complete \
test_job_fails \
test_join \
test_json \
*** ../vim-8.0.1241/src/eval.c  2017-10-30 21:48:36.482732724 +0100
--- src/eval.c  2017-11-02 15:33:14.077815209 +0100
***
*** 1056,1063 
if (str_arg_only)
len = 0;
else
!   /* Recognize a number argument, the others must be strings. */
vim_str2nr(argv[i], NULL, , STR2NR_ALL, , NULL, 0);
if (len != 0 && len == (int)STRLEN(argv[i]))
{
argvars[i].v_type = VAR_NUMBER;
--- 1056,1068 
if (str_arg_only)
len = 0;
else
!   {
!   /* Recognize a number argument, the others must be strings. A dash
!* is a string too. */
vim_str2nr(argv[i], NULL, , STR2NR_ALL, , NULL, 0);
+   if (len == 1 && *argv[i] == '-')
+   len = 0;
+   }
if (len != 0 && len == (int)STRLEN(argv[i]))
{
argvars[i].v_type = VAR_NUMBER;
*** ../vim-8.0.1241/src/version.c   2017-10-31 22:19:54.732086180 +0100
--- src/version.c   2017-11-02 15:34:27.661375669 +0100
***
*** 763,764 
--- 763,766 
  {   /* Add new patch number below this line */
+ /**/
+ 1242,
  /**/

-- 
BRIDGEKEEPER: What is your favorite editor?
GAWAIN:   Emacs ...  No, Viiimmm!
   "Monty Python and the Holy editor wars" PYTHON (MONTY) SOFTWARE LTD

 /// 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: Security risk of vim swap files

2017-11-02 Fir de Conversatie zdohnal
Hi Bram,

can VIm provide a way how to set permissions for swap files? So users which 
consider this VIm behavior as security risk can set permissions differently? 
Would that be possible for VIm (like setting set swap_file_perm=775 in vimrc 
file)?

-- 
-- 
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] added debian build badge

2017-11-02 Fir de Conversatie Tony Mechelynck
Well, if you decide to add more links for other distros, openSUSE does
distribute a Vim package (at the moment at version 7.4.326 without,
for some reason, patch 7.4.208). Bugs are reported via
https://bugzilla.opensuse.org in Product "openSUSE Distribution" and,
AFAICT, component "Other". But I doubt how useful it would be to link
to every single OS and distro where Vim happens to be able to run.

Best regards,
Tony.

-- 
-- 
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: Security risk of vim swap files

2017-11-02 Fir de Conversatie Bram Moolenaar

Ken Takata wrote:

> 2017/11/1 Wed 6:20:27 UTC+9 Bram Moolenaar wrote:
> > Hanno Böck wrote:
> > 
> > > I wanted to point out an issue here with vim swap files that make them
> > > a security problem.
> > > 
> > > By default vim creates a file with the name .filename.swp in the same
> > > directory while editing. They contain the full content of the edited
> > > file. This usually gets deleted upon exit, but not if vim crashes or
> > > gets killed (e.g. due to a reboot).
> > > 
> > > On web servers this can be a severe security risk. One can e.g. scan
> > > for web hosts that have swap files of PHP configuration files and thus
> > > expose settings like database passwords. (e.g. wget
> > > http://example.com/.wp-config.php.swp )
> > 
> > Why would a web server expose and serve such a file?  That clearly is
> > the problem, not that Vim happens to create swap files (and undo and
> > backup files, depending on your configuration).
> > 
> > You probably also create new files and copies of files that should not
> > be served.  If you care about security, the web server must always use
> > whitelisting, only serve files that were intentionally made public.
> > 
> > > In a scan of the alexa top 1 million I found ~750 instances of such
> > > files. I tried to inform affected people as best as I could. I also
> > > discovered such scans in my own web server logs, so I assume black hats
> > > are already aware of this and it's actively exploitet.
> > > 
> > > I was wondering how to best avoid this on my own servers and I first
> > > thought about saving the swap files to tmp ( with "set directory").
> > > However on multiuser systems this creates another security problem.
> > > These files are world readable, thus instead of leaking information to
> > > the world it's now leaking information to other users on the same
> > > system. Thus even if one is aware of the issue it's nontrivial to get
> > > secure settings (I've now worked around this by having per-user tmp
> > > dirs with secure permissions.)
> > > 
> > > I think vim should change the behavior of swap files:
> > > 1. they should be stored in /tmp by default
> > 
> > No, on Linux this is wiped clean on reboot.  You lose your work on a
> > system crash.
> > 
> > > 2. they should have secure permissions (tmp file security is
> > > a tricky thing and needs careful consideration to avoid symlink attacks
> > > and the like, but there are dedicated functions for this like mkstemp).
> > 
> > The permissions are the same as the original file, and that is exactly
> > how it should be.
> > 
> > > 3. Ideally they also shouldn't leak currently edited filenames (e.g.
> > > they shouldn't be called /tmp/.test.txt.swp, but more something
> > > like /tmp/.vim_swap.123782173)
> > 
> > Infeasible, Vim can't find that file when trying to recover the original
> > file.
> 
> An issue related to this (not the same) is filed as CVE-2017-1000382:
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000382
>   https://security-tracker.debian.org/tracker/CVE-2017-1000382
> 
> It seems that the problem is that Vim ignores umask:
>   http://www.openwall.com/lists/oss-security/2017/10/31/15
> 
> (Similar one for Emacs:
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383 )

This is working as intended, Vim does not use umask this way.
Umask is only used by simple commands such as cp, not by long running
processes that deal with many files.

Problem is with the user expectations.

-- 
Permission is granted to read this message out aloud on Kings Cross Road,
London, under the condition that the orator is properly dressed.

 /// 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] added debian build badge

2017-11-02 Fir de Conversatie James McCoy
On Thu, Nov 02, 2017 at 06:40:35AM +0100, Dominique Pellé wrote:
> Debian builds on many platforms which is useful
> to have a look at. It's currently using vim-8.0.1226.
> Glancing at those builds logs, I see:
> 
> - failures in Test_popup_and_window_resize() on at least mips
>   hppa, and sparc64 platforms, which are presumably fixed
>   in vim-8.0.1241

I've manually tested the fix on mips, but I'll be doing another upload
soon to see how broadly that works.

> - failures in Test_terminal_composing_unicode() and
>   Test_terminal_special_chars() on hppa platform, See:
>   
> https://buildd.debian.org/status/fetch.php?pkg=vim=hppa=2%3A8.0.1226-1=1509125272=0
> 
> - segfault in Test_finish_open_close() on hurd-386 platform.
>   See: 
> https://buildd.debian.org/status/fetch.php?pkg=vim=hurd-i386=2%3A8.0.1226-1=1509286549=0
> 
> - segfault on alpha platform. See:
>   
> https://buildd.debian.org/status/fetch.php?pkg=vim=alpha=2%3A8.0.1226-1=1509205720=0
> 
> Unfortunately, I see no stack trace when there is a
> segfault

I'll look into detecting crashes and logging backtraces into the build
log.  That would be useful for a first look at issues, especially since
not all of those architectures have accessible porterboxes.

> so I don't know how we can investigate crashes
> on hurd-386 and alphan platforms.

I'd be glad to sponsor[0] access to the porterboxes[1] if you want to
investigate more.  I could also use more help with the Debian packaging
if you're interested in that. ;-)

[0]: https://dsa.debian.org/doc/guest-account/
[1]: https://db.debian.org/machines.cgi?purpose=porterbox

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

-- 
-- 
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] added debian build badge

2017-11-02 Fir de Conversatie Dominique Pellé
Matěj Cepl  wrote:

> On 2017-11-02, 05:40 GMT, Dominique Pellé wrote:
>> I see that the neovim github page has a
>> debian CI badge. See:
>> https://github.com/neovim/neovim
>
> That seems like pretty silly thing to do (speaking me as user of
> Fedora/RHEL). Should vim carry some kind of badges for all (how
> many it is?) distros and operating systems it works on?

I don't think it's silly. It helps to find bugs in Vim on platforms
that are rarely used. I was not aware of vim crashes on alpha or
hurd x86 until I saw those debian test logs of vim-8.0.1241.
If someone has the time they could be investigated. We should
be able to run hurd with QEMU for example.

I don't think other distros build Vim on as many platforms as
debian, but if they they have useful pages with build status,
then having a badge that links to them would be fine with me.

For Fedora, I see this link:
https://koji.fedoraproject.org/koji/buildinfo?buildID=992971
... but it only seems to have compilation logs, not test logs
which it less useful than the debian page.

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: [patch] added debian build badge

2017-11-02 Fir de Conversatie Matěj Cepl
On 2017-11-02, 05:40 GMT, Dominique Pellé wrote:
> I see that the neovim github page has a
> debian CI badge. See:
> https://github.com/neovim/neovim

That seems like pretty silly thing to do (speaking me as user of 
Fedora/RHEL). Should vim carry some kind of badges for all (how 
many it is?) distros and operating systems it works on?

Best,

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
According to the Franciscan priest Richard Rohr, spirituality is
not for people who are trying to avoid hell; it is for people
who have been through hell. In many ways, spirituality is about
what we do with our pain. And the truth is, if we don't
transform it, we will transmit it.
-- Al Gustafson


-- 
-- 
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] 'set showcmd' messes up mappings when the {rhs} is longer than the screen width (#2268)

2017-11-02 Fir de Conversatie Christian Brabandt

On Do, 02 Nov 2017, Tony Mechelynck wrote:

> On Thu, Nov 2, 2017 at 9:54 AM, Christian Brabandt
>  wrote:
> > Okay, could finally reproduce it. This is really a subtle bug popping up.
> > This happens, because when executing your function, the command will be put
> > on the commandline, which causes a scroll. Vim then get's into the hit-enter
> > prompt and expects a character from the user. Now by coincidence the next
> > character in the typebuf is g which is a character that is accepted by the
> > hit-enter prompt and thus that character will be consumed and not available
> > for the normal mode command gv anymore.
> >
> > I think using the  flag should work around it, I think.
> >
> > Here is a patch, that basically skips putting the character on the
> > commandline, if they come from a mapping. I think we do not need to put the
> > characters to be executed on the commandline if they come from a mapping
> > (which should also save a redraw).
> 
> Isn't ":silent" enough? Or maybe a slight increase in 'cmdheight'? I
> have several mappings which execute short ex-commands, and I _like_
> seeing them echoed on the command-line.

That does not solve the problem that the mapping will do different 
things depending on the screen-width and is not portable/reproducible 
anymore.

Perhaps this patch is better:

diff --git a/src/message.c b/src/message.c
index 221e3d801..62c9f8f5a 100644
--- a/src/message.c
+++ b/src/message.c
@@ -1055,7 +1055,7 @@ wait_return(int redraw)

 redir_off = TRUE;  /* don't redirect this message */
 oldState = State;
-if (quit_more)
+if (quit_more || !typebuf_typed())
 {
c = CAR;/* just pretend CR was hit */
quit_more = FALSE;


Christian
-- 
Letzte Worte eines Co-Piloten:
  "Was meinst Du mit: 'Ich hab vergessen zu tanken.'"

-- 
-- 
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] 'set showcmd' messes up mappings when the {rhs} is longer than the screen width (#2268)

2017-11-02 Fir de Conversatie Tony Mechelynck
On Thu, Nov 2, 2017 at 9:54 AM, Christian Brabandt
 wrote:
> Okay, could finally reproduce it. This is really a subtle bug popping up.
> This happens, because when executing your function, the command will be put
> on the commandline, which causes a scroll. Vim then get's into the hit-enter
> prompt and expects a character from the user. Now by coincidence the next
> character in the typebuf is g which is a character that is accepted by the
> hit-enter prompt and thus that character will be consumed and not available
> for the normal mode command gv anymore.
>
> I think using the  flag should work around it, I think.
>
> Here is a patch, that basically skips putting the character on the
> commandline, if they come from a mapping. I think we do not need to put the
> characters to be executed on the commandline if they come from a mapping
> (which should also save a redraw).

Isn't ":silent" enough? Or maybe a slight increase in 'cmdheight'? I
have several mappings which execute short ex-commands, and I _like_
seeing them echoed on the command-line.

Best regards,
Tony.

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