Re: [vim/vim] 'set showcmd' messes up mappings when the {rhs} is longer than the screen width (#2268)
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.
Re: [vim/vim] 'set showcmd' messes up mappings when the {rhs} is longer than the screen width (#2268)
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: [patch] added debian build badge
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: [patch] added debian build badge
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
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&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 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: Security risk of vim swap files
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
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
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.
Patch 8.0.1242
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, &len, STR2NR_ALL, &n, 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, &len, STR2NR_ALL, &n, 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: Patch 8.0.1227
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.1243
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
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.
Re: Patch 8.0.1238
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
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.
Patch 8.0.1245
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, &modifiable) --- 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, &modifiable) *** *** 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, &modifiable) --- 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, &modifiable) *** *** 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)
Re: [patch] added debian build badge
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.
Re: Patch 8.0.1238
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 8.0.1241
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.
Patch 8.0.1246
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
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] added debian build badge
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&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. 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.1247
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&service=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.
Patch 8.0.1248
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&service=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&service=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.1249
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.
Re: [patch] added debian build badge
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.
Re: [patch] added debian build badge
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.
Patch 8.0.1250
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(&t); 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&vim + 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)
Patch 8.0.1251
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.1252
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: ! $(LS
Re: [patch] Update makefiles in src/po/
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.
Re: Security risk of vim swap files
* 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 8.0.1248
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&service=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? ##
Patch 8.0.1253
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: Security risk of vim swap files
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 per
Re: Security risk of vim swap files
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.
Patch 8.0.1254
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 8
Patch 8.0.1255
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&service=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&service=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.
Re: Patch 8.0.1248
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.
Re: Security risk of vim swap files
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.
Patch 8.0.1256
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
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 "vim_dev
Patch 8.0.1257
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.
Odd behavior of vim 8.0.1203 in a wide xterm
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.
Re: Odd behavior of vim 8.0.1203 in a wide xterm
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.
Re: Odd behavior of vim 8.0.1203 in a wide xterm
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
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
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: Security risk of vim swap files
* 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: [doc][patch] Update documents
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 >= {lnum
Re: Odd behavior of vim 8.0.1203 in a wide xterm -- solution found
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.