[patch] added debian build badge
Hi 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&arch=hppa&ver=2%3A8.0.1226-1&stamp=1509125272&raw=0 - segfault in Test_finish_open_close() on hurd-386 platform. See: https://buildd.debian.org/status/fetch.php?pkg=vim&arch=hurd-i386&ver=2%3A8.0.1226-1&stamp=1509286549&raw=0 - segfault on alpha platform. See: https://buildd.debian.org/status/fetch.php?pkg=vim&arch=alpha&ver=2%3A8.0.1226-1&stamp=1509205720&raw=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. 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 53795a7..b60b6b6 100644 --- a/README.md +++ b/README.md @@ -4,6 +4,7 @@ [](https://coveralls.io/github/vim/vim?branch=master) [](https://ci.appveyor.com/project/chrisbra/vim) [](https://scan.coverity.com/projects/vim) +[](https://buildd.debian.org/vim)[](https://buildd.debian.org/vim) ## What is Vim? ##
Re: Security risk of vim swap files
Hi,
2017/11/1 Wed 12:32:43 UTC+9 Ken Takata wrote:
> Hi,
>
> 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 )
How about the attached patch?
This makes Vim to respect umask when creating a swapfile.
(I'm not sure this is actually needed, though.)
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 8a009ace74e43d2117cc4a17600b3de60ab08de4
diff --git a/src/fileio.c b/src/fileio.c
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -509,9 +509,16 @@ readfile(
* (they must not write the swapfile).
* Add the "read" and "write" bits for the user, otherwise we may
* not be able to write to the file ourselves.
+ * Also respect umask.
* Setting the bits is done below, after creating the swap file.
*/
- swap_mode = (st.st_mode & 0644) | 0600;
+ {
+ mode_t umask_save;
+
+ umask_save = umask(0); /* Get current umask. */
+ (void)umask(umask_save);
+ swap_mode = (st.st_mode & 0644 & ~umask_save) | 0600;
+ }
#endif
#ifdef FEAT_CW_EDITOR
/* Get the FSSpec on MacOS
Re: Patch 8.0.1241
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. 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)
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 8.0.1241
James McCoy wrote:
> On Tue, Oct 31, 2017 at 10:20:14PM +0100, Bram Moolenaar wrote:
> > *** ../vim-8.0.1240/src/testdir/test_popup.vim 2017-10-27
> > 01:34:55.093306847 +0200
> > --- src/testdir/test_popup.vim 2017-10-31 22:15:48.865608389 +0100
> > ***
> > *** 639,645
> > 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, 200)
> > call term_sendkeys(g:buf, "Gi\")
> > call term_sendkeys(g:buf, "\")
> > call term_wait(g:buf, 100)
> > --- 639,645
> > 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)
>
> Wouldn't something more deterministic be better? How about this?
>
> diff --git i/src/testdir/test_popup.vim w/src/testdir/test_popup.vim
> index 2781aabcd..a4bed18d9 100644
> --- i/src/testdir/test_popup.vim
> +++ w/src/testdir/test_popup.vim
> @@ -639,7 +639,8 @@ func Test_popup_and_window_resize()
>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)
> + " Wait for the nested Vim to exit insert mode, where it will show the ruler
> + call WaitFor(printf('term_getline(g:buf, %d) =~ "\<%d,1\>"', h, h / 3))
>call term_sendkeys(g:buf, "Gi\")
>call term_sendkeys(g:buf, "\")
>call term_wait(g:buf, 100)
That's defenitely better than an arbitrary delay. However, I think your
check just never matches and causes a delay of one second.
--
Sorry, no fortune today.
/// 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] some small fixes for the incsearch test
Bram,
attached patch contains the fixes discussed at
https://github.com/vim/vim/issues/2267 including some tests.
Those newly added (or changed) tests are:
- Test_search_cmdline6
makes sure, that will skip to the next pattern and does not skip
consecutive patterns
- Test_search_cmdline7
makes sure, that does not move the cursor, if no pattern has
been entered (and so does not move to the previous used pattern)
(This might have been a feature for some people, however in #2267
it was considered a bug, so I removed that "feature").
Fix is courtesy of h-east
- Test_search_cmdline8
make sure, that all windows are redrawn after leaving the commandline.
This makes sense, since the hlsearch pattern applies globally to all
windows. Fix is courtesy of haya14busa
Note: The test does not fail on an unpatched Vim, however when run
interactively it works correctly. Don't know why this happens.
- Test_search_cmdline_incsearch_highlight_attr
Fix that this does not work on Windows (as mentioned in
https://groups.google.com/d/msg/vim_dev/YvyOOnc3KW0/wTPvl2bIBgAJ)
It includes the fix for the test from that message.
It also throws skipped on Windows, as `term_sendkeys(...,"\")` does
not work correctly on windows and this is needed to verify that
Test_search_cmdline8 works correctly.
It also contains a bugfix for the documentation:
- autocmd CmdlineEnter [/\?] :set hlsearch
- autocmd CmdlineLeave [/\?] :set nohlsearch
+ autocmd CmdlineEnter /,\? :set hlsearch
+ autocmd CmdlineLeave /,\? :set nohlsearch
This does not work on Windows. Don't know why. Somehow the cmdwin-char
for forward search seems to be `\` on a windows machine, at least this
is what I get with
,
| au CmdlineEnter * :echomsg expand("")
`
However, this does not explain, why the pattern /,\? works. But since it
does, I just updated the documentation. Another pattern that works would
be `[/\\?]`
Christian
--
Meinungen sind wie Grundstücke: Erstens sind sie zu teuer, und
zweitens kann man nicht immer darauf bauen.
-- Dieter Hildebrandt
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From a1e88ac0b2fa8b2a10a730b86ce3da85104ab0f7 Mon Sep 17 00:00:00 2001
From: Christian Brabandt
Date: Wed, 1 Nov 2017 17:01:21 +0100
Subject: [PATCH] Some small fixes for incsearch feature
---
runtime/doc/options.txt | 4 +-
src/ex_getln.c | 10 +++-
src/testdir/test_search.vim | 119 ++--
3 files changed, 127 insertions(+), 6 deletions(-)
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
index 0a07cc257..b006dc61a 100644
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -4515,8 +4515,8 @@ A jump table for the options with a short description can be found at |Q_op|.
Example: >
augroup vimrc-incsearch-highlight
autocmd!
- autocmd CmdlineEnter [/\?] :set hlsearch
- autocmd CmdlineLeave [/\?] :set nohlsearch
+ autocmd CmdlineEnter /,\? :set hlsearch
+ autocmd CmdlineLeave /,\? :set nohlsearch
augroup END
<
CTRL-L can be used to add one character from after the current match
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 717a01224..027047728 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -1717,12 +1717,19 @@ getcmdline(
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(&t);
search_flags += SEARCH_COL;
}
else
@@ -1945,6 +1952,7 @@ cmdline_changed:
{
i = 0;
SET_NO_HLSEARCH(TRUE); /* turn off previous highlight */
+ redraw_all_later(SOME_VALID);
}
else
{
@@ -2082,7 +2090,7 @@ returncmd:
curwin->w_botline = old_botline;
highlight_match = FALSE;
validate_cursor(); /* needed for TAB */
- redraw_later(SOME_VALID);
+ redraw_all_later(SOME_VALID);
}
#endif
diff --git a/src/testdir/test_search.vim b/src/testdir/test_search.vim
index b863fcbba..ab599fe4d 100644
--- a/src/testdir/test_search.vim
+++ b/src/testdir/test_search.vim
@@ -397,6 +397,117 @@ func Test_search_cmdline5()
bw!
endfunc
+func Test_search_cmdline6()
+ " Test that consecutive matches
+ " are caught by /
+ if !exists('+incsear
[patch] Update makefiles in src/po/
Hi, 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. 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 d9f39932dea38404dceb4421a754bdfe167ffaea diff --git a/src/po/Make_ming.mak b/src/po/Make_ming.mak --- a/src/po/Make_ming.mak +++ b/src/po/Make_ming.mak @@ -11,7 +11,11 @@ # ifndef VIMRUNTIME +ifeq (sh.exe, $(SHELL)) VIMRUNTIME = ..\..\runtime +else +VIMRUNTIME = ../../runtime +endif endif LANGUAGES = \ @@ -100,14 +104,27 @@ PACKAGE = vim #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 @@ -136,10 +153,18 @@ install: $(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 # HG changeset patch # Parent 57916746642402e28f9d8b465aa1ab3cc24a2b46 diff --git a/src/po/Make_cyg.mak b/src/po/Make_cyg.mak --- a/src/po/Make_cyg.mak +++ b/src/po/Make_cyg.mak @@ -128,11 +128,11 @@ all: $(MOFILES) first_time: $(XGETTEXT) --default-domain=$(LANGUAGE) \ - --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) ../if_perl.xs $(wildcard ../globals.h) + --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 $(wildcard ../globals.h) + --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 diff --git a/src/po/Make_ming.mak b/src/po/Make_ming.mak --- a/src/po/Make_ming.mak +++ b/src/po/Make_ming.mak @@ -137,11 +137,11 @@ all: $(MOFILES) first_time: $(XGETTEXT) --default-domain=$(LANGUAGE) \ - --add-comments --keyword=_ --keyword=N_ $(wildcard ../*.c) ../if_perl.xs $(wildcard ../globals.h) + --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 $(wildcard ../globals.h) + --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 diff --git a/src/po/Make_mvc.mak b/src/po/Make_mvc.mak --- a/src/po/Make_mvc.mak +++ b/src/po/Make_mvc.mak @@ -117,7 +117,7 @@ INSTALLDIR = $(VIMRUNTIME)\lang\$(LANGUA all: $(MOFILES) files: - $(LS) $(LSFLAGS) ..\*.c ..\if_perl.xs ..\globals.h > .\files + $(LS) $(LSFLAGS) ..\*.c ..\if_perl.xs ..\GvimExt\gvimext.cpp ..\globals.h ..\if_py_both.h > .\files first_time: files set OLD_PO_FILE_INPUT=yes
Re: Patch 8.0.1238
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.
I don't know why this is so here is a patch, that uses a temp file as a
workaround.
diff --git a/src/testdir/test_search.vim b/src/testdir/test_search.vim
index b863fcbba..361df8069 100644
--- a/src/testdir/test_search.vim
+++ b/src/testdir/test_search.vim
@@ -494,13 +494,14 @@ func Test_search_cmdline_incsearch_highlight_attr()
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 writefile(lines, 'Xsearch.txt')
+ let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile',
'Xsearch.txt'], {'term_rows': 3})
+
call term_wait(g:buf, 200)
call assert_equal(lines[0], term_getline(g:buf, 1))
+ call assert_equal(lines[1], term_getline(g:buf, 2))
" Get attr of normal(a0), incsearch(a1), hlsearch(a2) highlight
call term_sendkeys(g:buf, ":set incsearch hlsearch\")
@@ -564,6 +565,7 @@ func Test_search_cmdline_incsearch_highlight_attr()
let attr_line2 = [a0,a0,a0,a0,a0,a0,a0,a0]
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
Christian
--
Hart ist Hart. Weich ist Weich. Aber immer weich ist hart.
--
--
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 7.3
On Mi, 01 Nov 2017, Tony Mechelynck wrote: > Another thing I don't like (or maybe don't understand) in git is the > existence of "garbage collection". On the contrary, a basic tenet of > Mercurial philosophy is that history is frozen in stone, so if I let a > clone stand without updating it for, let's say, a year, and then run > "hg pull -u" or "hg fetch", Mercurial will be able to continue from > where I left off and (barring timeouts and brownouts) get the clone > back up to date. Once I did that with git, and when I came back after > a year my clone was so hopelessly out of date that git didn't know how > to update it: the only way I found to make it up to date again was to > delete the clone and make a new one. If I understood correctly garbage collection in git, this only affects any object, that is not reachable, so it should in practice not matter for the usual case. > P.S. Happily for me, Christian understands both of them (or ;-) seems > to) More or less :) Christian -- Der Begriff "Fortschritt" allein setzt bereits die Horizontale voraus. Er bedeutet ein Weiterkommen und keine Höherkommen. -- Joseph Roth -- -- 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.
