Re: [vim/vim] :cexpr and :cgetexpr not included in QuickFixCmdPre/QuickFixCmdPost autocmd triggers (#1021)
Hi, On Mon, Aug 29, 2016 at 7:38 PM, Mathias Stearn wrote: > > QuickFixCmdPost can be used to automatically show the quickfix window > whenever a command runs that affects the quickfix list. This seems to work > for everything except for :cexpr, which looks like it was accidentally > omitted from the list of triggering commands. If it was intentional, it may > be worth mentioning explicitly in the docs. > As mentioned in the help, the QuickFixCmdPre/Post autocmds are used only for commands like grep, make, vimgrep and cscope that add/modify the quickfix list. They are not used for commands like cfile, cbuffer and cexpr etc. The help text for cexpr can be updated to state this. - Yegappan -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: system() delay
On Monday, August 29, 2016 at 8:35:33 AM UTC+3, Dominique Pelle wrote: > Ramel wrote: > > > Nice catch! > > My 'shell' was tcsh and after changing it to /bin/sh (=bash) System() works > > much better (only ~x2 slower than Job()). I probably wouldn't get into this > > if I got these results in the first place.. still, I'm going to use the > > above blocking version of job_start (it is as fast as Job()) since in RHEL > > everything is slower by a factor of 10(!) anyway. > > > > Thanks, > > Ramel > > Hi Ramel > > Can you provide the timings with at least 3 runs as I did on RHEL? > > And can you attach the output of the strace command on RHEL? > I.e. run: > > $ strace -r -f -osystem.trace time vim -u NONE -N -S system.vim -c > 'call System()|q' > > $ strace -r -f -ojob.trace time vim -u NONE -N -S system.vim -c > 'call Job()|q' > > And attach files jobs.trace and system.trace. Please also indicate > which version of vim you used. > > Thanks > Dominique > > PS: please use bottom-post in vim-dev. Hi Dominique, Sorry, but the RHEL is at my work and the trace files are relatively big and contain confidential details.. You can see the timings below. Thanks, Ramel RHEL 5.5 (using shell=bash) Job(): aaa: 0.012400 aaa: 0.011879 aaa: 0.012227 System(): aaa: 0.053787 aaa: 0.054384 aaa: 0.053694 Ubuntu 16.04: Job(): aaa: 0.001710 aaa: 0.001692 aaa: 0.001673 System(): aaa: 0.010966 aaa: 0.010938 aaa: 0.010940 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Small doc fixes for lambda
Hi, 2016/8/30 Tue 4:56:01 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > > 2016/8/29 Mon 4:21:51 UTC+9 Bram Moolenaar wrote: > > > Manuel Ortega wrote: > > > > > > > At ":h lambda", there is some erroneous markup. It mistakenly is > > > > "|expr1|", which takes the user to the help for the ternary > > > > conditional! > > > > > > That is correct. This is the higest level expression. It's clearer if > > > you start with reading ":help expression-syntax". > > > > I think I found some mistakes in ":help expression-syntax". > > Please check the attached patch. Misalignment is also fixed. > > Hmm, some things were correct. For example: > > |expr7| ! expr7 logical NOT > - expr7 unary minus > + expr7 unary plus > > This means you can use !!expr7, !-!expr7, etc. Ah! You are right. > It doesn't mention that expr7 can be expr8, that applies to all of them. > Does it help to add them anyway? Like this: > > |expr7| expr8 > ! expr7 logical NOT > - expr7 unary minus > + expr7 unary plus Now it becomes clear to me. 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.
Patch 7.4.2294
Patch 7.4.2294
Problem:Sign test fails on MS-Windows when using the distributed zip
archives.
Solution: Create dummy files instead of relying on files in the pixmaps
directory.
Files: src/testdir/test_signs.vim
*** ../vim-7.4.2293/src/testdir/test_signs.vim 2016-08-17 22:29:06.158531366
+0200
--- src/testdir/test_signs.vim 2016-08-29 23:03:25.385276249 +0200
***
*** 145,152
call feedkeys(":sign define Sign linehl=Spell\\\"\", 'tx')
call assert_equal('"sign define Sign linehl=SpellBad SpellCap SpellLocal
SpellRare', @:)
! call feedkeys(":sign define Sign
icon=../../pixmaps/tb_p\\\"\", 'tx')
! call assert_equal('"sign define Sign icon=../../pixmaps/tb_paste.xpm
../../pixmaps/tb_print.xpm', @:)
call feedkeys(":sign undefine \\\"\", 'tx')
call assert_equal('"sign undefine Sign1 Sign2', @:)
--- 145,156
call feedkeys(":sign define Sign linehl=Spell\\\"\", 'tx')
call assert_equal('"sign define Sign linehl=SpellBad SpellCap SpellLocal
SpellRare', @:)
! call writefile(['foo'], 'XsignOne')
! call writefile(['bar'], 'XsignTwo')
! call feedkeys(":sign define Sign icon=Xsig\\\"\", 'tx')
! call assert_equal('"sign define Sign icon=XsignOne XsignTwo', @:)
! call delete('XsignOne')
! call delete('XsignTwo')
call feedkeys(":sign undefine \\\"\", 'tx')
call assert_equal('"sign undefine Sign1 Sign2', @:)
*** ../vim-7.4.2293/src/version.c 2016-08-29 22:48:12.177105943 +0200
--- src/version.c 2016-08-29 23:05:36.964144542 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2294,
/**/
--
hundred-and-one symptoms of being an internet addict:
109. You actually read -- and enjoy -- lists like this.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.2293
Patch 7.4.2293 Problem:Modelines in source code are inconsistant. Solution: Use the same line in most files. Add 'noet'. (Naruhiko Nishino) Files: src/alloc.h, src/arabic.c, src/arabic.h, src/ascii.h, src/blowfish.c, src/buffer.c, src/channel.c, src/charset.c, src/crypt.c, src/crypt_zip.c, src/dict.c, src/diff.c, src/digraph.c, src/dosinst.c, src/dosinst.h, src/edit.c, src/eval.c, src/evalfunc.c, src/ex_cmds.c, src/ex_cmds.h, src/ex_cmds2.c, src/ex_docmd.c, src/ex_eval.c, src/ex_getln.c, src/farsi.c, src/farsi.h, src/feature.h, src/fileio.c, src/fold.c, src/getchar.c, src/glbl_ime.cpp, src/glbl_ime.h, src/globals.h, src/gui.c, src/gui.h, src/gui_at_fs.c, src/gui_at_sb.c, src/gui_at_sb.h, src/gui_athena.c, src/gui_beval.c, src/gui_beval.h, src/gui_gtk.c, src/gui_gtk_f.c, src/gui_gtk_f.h, src/gui_gtk_vms.h, src/gui_gtk_x11.c, src/gui_mac.c, src/gui_motif.c, src/gui_photon.c, src/gui_w32.c, src/gui_x11.c, src/gui_x11_pm.h, src/gui_xmdlg.c, src/gui_xmebw.c, src/gui_xmebw.h, src/gui_xmebwp.h, src/hangulin.c, src/hardcopy.c, src/hashtab.c, src/if_cscope.c, src/if_cscope.h, src/if_mzsch.c, src/if_mzsch.h, src/if_ole.cpp, src/if_perl.xs, src/if_perlsfio.c, src/if_python3.c, src/if_ruby.c, src/if_tcl.c, src/if_xcmdsrv.c, src/integration.c, src/integration.h, src/iscygpty.c, src/json.c, src/json_test.c, src/keymap.h, src/list.c, src/macros.h, src/main.c, src/mark.c, src/mbyte.c, src/memfile.c, src/memfile_test.c, src/memline.c, src/menu.c, src/message.c, src/message_test.c, src/misc1.c, src/misc2.c, src/move.c, src/nbdebug.c, src/nbdebug.h, src/netbeans.c, src/normal.c, src/ops.c, src/option.c, src/option.h, src/os_amiga.c, src/os_amiga.h, src/os_beos.c, src/os_beos.h, src/os_dos.h, src/os_mac.h, src/os_mac_conv.c, src/os_macosx.m, src/os_mint.h, src/os_mswin.c, src/os_qnx.c, src/os_qnx.h, src/os_unix.c, src/os_unix.h, src/os_unixx.h, src/os_vms.c, src/os_w32dll.c, src/os_w32exe.c, src/os_win32.c, src/os_win32.h, src/popupmnu.c, src/proto.h, src/pty.c, src/quickfix.c, src/regexp.c, src/regexp.h, src/regexp_nfa.c, src/screen.c, src/search.c, src/sha256.c, src/spell.c, src/spell.h, src/spellfile.c, src/structs.h, src/syntax.c, src/tag.c, src/term.c, src/term.h, src/termlib.c, src/ui.c, src/undo.c, src/uninstal.c, src/userfunc.c, src/version.c, src/version.h, src/vim.h, src/vim.rc, src/vimio.h, src/vimrun.c, src/winclip.c, src/window.c, src/workshop.c, src/workshop.h, src/wsdebug.c, src/wsdebug.h, src/xpm_w32.c *** ../vim-7.4.2292/src/alloc.h 2016-02-27 15:21:28.404383974 +0100 --- src/alloc.h 2016-08-29 22:42:14.940190496 +0200 *** *** 1,4 ! /* vi:set ts=8 sts=4 sw=4: * * VIM - Vi IMproved by Bram Moolenaar * --- 1,4 ! /* vi:set ts=8 sts=4 sw=4 noet: * * VIM - Vi IMproved by Bram Moolenaar * *** ../vim-7.4.2292/src/arabic.c2016-07-02 20:27:29.953436359 +0200 --- src/arabic.c2016-08-29 22:39:44.245496743 +0200 *** *** 1,4 ! /* vi:set ts=8 sts=4 sw=4: * * VIM - Vi IMprovedby Bram Moolenaar * --- 1,4 ! /* vi:set ts=8 sts=4 sw=4 noet: * * VIM - Vi IMprovedby Bram Moolenaar * *** ../vim-7.4.2292/src/arabic.h2010-05-15 13:04:07.0 +0200 --- src/arabic.h2016-08-29 22:42:20.940138507 +0200 *** *** 1,4 ! /* vi:set ts=8 sts=4 sw=4: * * VIM - Vi IMprovedby Bram Moolenaar * --- 1,4 ! /* vi:set ts=8 sts=4 sw=4 noet: * * VIM - Vi IMprovedby Bram Moolenaar * *** ../vim-7.4.2292/src/ascii.h 2015-07-10 14:05:03.930436893 +0200 --- src/ascii.h 2016-08-29 22:42:20.940138507 +0200 *** *** 1,4 ! /* vi:set ts=8 sts=4 sw=4: * * VIM - Vi IMproved by Bram Moolenaar * --- 1,4 ! /* vi:set ts=8 sts=4 sw=4 noet: * * VIM - Vi IMproved by Bram Moolenaar * *** ../vim-7.4.2292/src/blowfish.c 2016-02-23 14:52:31.865232378 +0100 --- src/blowfish.c 2016-08-29 22:42:20.940138507 +0200 *** *** 1,4 ! /* vi:set ts=8 sts=4 sw=4: * * VIM - Vi IMproved by Bram Moolenaar * --- 1,4 ! /* vi:set ts=8 sts=4 sw=4 noet: * * VIM - Vi IMproved by Bram Moolenaar * *** ../vim-7.4.2292/src/buffer.c2016-08-24 00:12:08.864171037 +0200 --- src/buffer.c2016-08-29 22:42:20.944138473 +0200 *** *** 1,4 ! /* vi:set ts=8 sts=4 sw=4: * * VIM - Vi IMproved by Bram Moolenaar * --- 1,4 ! /* vi:set ts=8 sts=4 sw=4 noet: * * VIM - Vi IMproved by Bram Moolenaar * *** ../vim-7.4.2292/src/channel.c
Patch 7.4.2292
Patch 7.4.2292 (after 7.4.2291)
Problem:Not all systems understand %F in printf().
Solution: Use %f.
Files: src/message.c
*** ../vim-7.4.2291/src/message.c 2016-08-29 21:55:16.360528486 +0200
--- src/message.c 2016-08-29 22:25:08.441090524 +0200
***
*** 4797,4803
precision = max_prec;
l += sprintf(format + l, ".%d", (int)precision);
}
! format[l] = fmt_spec;
format[l + 1] = NUL;
str_arg_l = sprintf(tmp, format, f);
--- 4797,4803
precision = max_prec;
l += sprintf(format + l, ".%d", (int)precision);
}
! format[l] = fmt_spec == 'F' ? 'f' : fmt_spec;
format[l + 1] = NUL;
str_arg_l = sprintf(tmp, format, f);
*** ../vim-7.4.2291/src/version.c 2016-08-29 21:55:16.360528486 +0200
--- src/version.c 2016-08-29 22:26:50.300205471 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2292,
/**/
--
hundred-and-one symptoms of being an internet addict:
107. When using your phone you forget that you don't have to use your
keyboard.
/// 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] mention skipped tests for new_style tests
Christian Brabandt wrote: > Hi, > while working on some more tests, I noticed some bugs. I will report > them separately, whenever I have a test, that is reproducible > stand-alone, but until then, I like to disable some tests (and don't > forget about them). > > However, it would be nice, if the logfile could mention, if a test has > been skipped, and which one. > > Therefore here is a patch, that adds this ability. See the commit > message for an detailed explanation. Hmm, this looks a bit complicated. I can think of two alternatives: 1. Name the test Test_skip_my_test() Then the runtest script can report Executing Test_normal11_showcmd() SKIPPING Test_skip_my_test() 2. Throw the reason: func Test_my_stuff() throw 'skipped: need to fix the bug first' ... Then runtest would report Executing Test_my_stuff() SKIPPED Although completely commenting out the function also works. -- hundred-and-one symptoms of being an internet addict: 106. When told to "go to your room" you inform your parents that you can't...because you were kicked out and banned. /// 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: Will the default 8-bit meta mode in vim conflict with utf-8 characters in terminal ?
skywind3000 wrote: > As ':help :map-alt-keys': > > By default Vim assumes that pressing the ALT key sets the 8th bit of a typed > character. Most decent terminals can work that way, such as xterm, aterm and > rxvt. If your mappings don't work it might be that the terminal is > prefixing the character with an ESC character. But you can just as well type > ESC before a character, thus Vim doesn't know what happened (except for > checking the delay between characters, which is not reliable). > > As of this writing, some mainstream terminals like gnome-terminal and konsole > use the ESC prefix. There doesn't appear a way to have them use the 8th bit > instead. Xterm should work well by default. Aterm and rxvt should work well > when started with the "--meta8" argument. You can also tweak resources like > "metaSendsEscape", "eightBitInput" and "eightBitOutput". > - > > in the modern terminals (like iTerm / gnome-terminal), typing unicode > characters will be encoded as utf-8 and transfer to vim, which may > contains the 8th bit. > > Will vim recognize utf-8 data stream as some meta-* key strokes ? > > Should I always set - to ^[a - ^[z in terminal to avoid > that mistake ? Sure, setting the 8th bit and then utf-8 encoding it works just fine. The mode where pressing Alt results in prepending ESC is something that should never have happened, it was a mistake. -- Laughing helps. It's like jogging on the inside. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: bug with folding
Hi Bram! On Mo, 29 Aug 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > I am currently writing some tests for normal.c, to increase the coverage. > > > > Unfortunately, I noteiced some bugs with folding: Here is one issue: > > > > ~$ vim -u NONE -N > > call setline(1, range(1,10) > > :3 > > norm! 2zF > > :2 > > norm! 5zF > > :set nofoldenable > > :3 > > norm! zc -> folds line 2 - 8, I would have expected to only close the > > inner fold 3-4, but perhaps that is expected, but see below: > > set nofoldenable > > norm! Vzc -> correctly folds 3-4 > > :set nofoldenable > > norm! zc -> folds lines 3-4? > > Isn't this because 'foldlevel' keeps the same value when 'foldenable' is > reset? But I never messed with the foldlevel setting. Also, it seems, it is not so easily reproducible, as I initially thought. Sometimes it happens for me, and sometimes it always folds lines 2-8 but I never saw that it changes the foldlevel setting > > Also I got another session, where zF create one additional closing > > fold marker several lines below where it definitly shouldn't. > > Unfortunately, I can't reproduce this problem anymore. > > The rules for opening a closing folds are a bit complicated... > It's possible there is a bug, but it's also possible that something is > missing in the documentation. I notice "zc" doesn't say anything about > 'foldlevel'. Adding to the documentation does help, as I only test according to the documentation and do not read the source. Hm, will have to further investigate. Best, Christian -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] fixed more issues with printf() with float numbers
Dominique Pellé wrote:
> Attached patch fixes further problems with printf()
> for floats in Vim-7.4.2290.
>
> Padding with 0 did not work properly when there is a sign:
>
> :echo printf("%06.2f", -1.0)
> Actual: "0-1.00"
> Expected: "-01.00"
>
> Forcing sign was not honored:
>
> :echo printf("%+.2f", 1.0)
> Actual: "1.00"
> Expected: "+1.00"
>
> %F was the same as %f, but it should differ for INF and NAN:
>
> :echo printf("%F", 1.0/0.0)
> Actual: inf
> Expected: INF
>
> As far as I can tell, all issues I described earlier with
> printf() should now be fixed.
>
> Patch also slightly improves test coverage of printf().
Thanks!
--
hundred-and-one symptoms of being an internet addict:
103. When you find yourself in the "Computer" section of Barnes & Noble
enjoying yourself.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.2291
Patch 7.4.2291
Problem:printf() handles floats wrong when there is a sign.
Solution: Fix placing the sign. Add tests. (Dominique Pelle)
Files: src/testdir/test_expr.vim, runtime/doc/eval.txt, src/message.c
*** ../vim-7.4.2290/src/testdir/test_expr.vim 2016-08-28 16:03:34.824991857
+0200
--- src/testdir/test_expr.vim 2016-08-29 21:45:35.009473848 +0200
***
*** 162,182
call assert_equal(' +123', printf('%+6d', 123))
call assert_equal(' 123', printf('% 6d', 123))
call assert_equal(' -123', printf('% 6d', -123))
call assert_equal('+123 ', printf('%-+6d', 123))
call assert_equal(' 123 ', printf('%- 6d', 123))
call assert_equal('-123 ', printf('%- 6d', -123))
call assert_equal('00123', printf('%.*d', 5, 123))
call assert_equal(' 123', printf('% *d', 5, 123))
call assert_equal(' +123', printf('%+ *d', 5, 123))
! call assert_equal('123 ', printf('%-5d', 123))
call assert_equal('0x7b', printf('%#x', 123))
call assert_equal('0X7B', printf('%#X', 123))
call assert_equal('0173', printf('%#o', 123))
call assert_equal('0173', printf('%#O', 123))
call assert_equal('abc', printf('%#s', 'abc'))
call assert_equal('abc', printf('%#S', 'abc'))
call assert_equal(' 00123', printf('%6.5d', 123))
call assert_equal(' 0007b', printf('%6.5x', 123))
--- 162,205
call assert_equal(' +123', printf('%+6d', 123))
call assert_equal(' 123', printf('% 6d', 123))
call assert_equal(' -123', printf('% 6d', -123))
+
+ " Test left adjusted.
+ call assert_equal('123 ', printf('%-6d', 123))
call assert_equal('+123 ', printf('%-+6d', 123))
call assert_equal(' 123 ', printf('%- 6d', 123))
call assert_equal('-123 ', printf('%- 6d', -123))
+ call assert_equal(' 00123', printf('%7.5d', 123))
+ call assert_equal(' -00123', printf('%7.5d', -123))
+ call assert_equal(' +00123', printf('%+7.5d', 123))
+ " Precision field should not be used when combined with %0
+ call assert_equal(' 00123', printf('%07.5d', 123))
+ call assert_equal(' -00123', printf('%07.5d', -123))
+
+ call assert_equal(' 123', printf('%*d', 5, 123))
+ call assert_equal('123 ', printf('%*d', -5, 123))
call assert_equal('00123', printf('%.*d', 5, 123))
call assert_equal(' 123', printf('% *d', 5, 123))
call assert_equal(' +123', printf('%+ *d', 5, 123))
! " Simple quote (thousand grouping char) is ignored.
! call assert_equal('+00123456', printf("%+'09d", 123456))
!
! " Unrecognized format specifier kept as-is.
! call assert_equal('_123', printf("%_%d", 123))
!
! " Test alternate forms.
call assert_equal('0x7b', printf('%#x', 123))
call assert_equal('0X7B', printf('%#X', 123))
call assert_equal('0173', printf('%#o', 123))
call assert_equal('0173', printf('%#O', 123))
call assert_equal('abc', printf('%#s', 'abc'))
call assert_equal('abc', printf('%#S', 'abc'))
+ call assert_equal(' 0173', printf('%#6o', 123))
+ call assert_equal(' 00173', printf('%#6.5o', 123))
+ call assert_equal(' 0173', printf('%#6.2o', 123))
+ call assert_equal(' 0173', printf('%#6.2o', 123))
+ call assert_equal('0173', printf('%#2.2o', 123))
call assert_equal(' 00123', printf('%6.5d', 123))
call assert_equal(' 0007b', printf('%6.5x', 123))
***
*** 201,206
--- 224,230
function Test_printf_float()
if has('float')
+ call assert_equal('1.00', printf('%f', 1))
call assert_equal('1.23', printf('%f', 1.23))
call assert_equal('1.23', printf('%F', 1.23))
call assert_equal('999.9', printf('%g', 999.9))
***
*** 215,224
call assert_equal(' 0.33', printf('%6.2f', 1.0/3.0))
call assert_equal(' -0.33', printf('%6.2f', -1.0/3.0))
call assert_equal('000.33', printf('%06.2f', 1.0/3.0))
! " FIXME: call assert_equal('-00.33', printf('%06.2f', -1.0/3.0))
! " FIXME: call assert_equal('-00.33', printf('%+06.2f', -1.0/3.0))
! " FIXME: call assert_equal('+00.33', printf('%+06.2f', 1.0/3.0))
! " FIXME: call assert_equal(' 00.33', printf('% 06.2f', 1.0/3.0))
" Float infinity can be signed.
call assert_equal('inf', printf('%f', 1.0/0.0))
--- 239,269
call assert_equal(' 0.33', printf('%6.2f', 1.0/3.0))
call assert_equal(' -0.33', printf('%6.2f', -1.0/3.0))
call assert_equal('000.33', printf('%06.2f', 1.0/3.0))
! call assert_equal('-00.33', printf('%06.2f', -1.0/3.0))
! call assert_equal('-00.33', printf('%+06.2f', -1.0/3.0))
! call assert_equal('+00.33', printf('%+06.2f', 1.0/3.0))
! call assert_equal(' 00.33', printf('% 06.2f', 1.0/3.0))
! call assert_equal('000.33', printf('%06.2g', 1.0/3.0))
! call assert_equal('-00.33', printf('%06.2g', -1.0/3.0))
! call assert_equal('0.33', printf('%3.2f', 1.0/3.0))
! call assert_equal('003.33e-01', printf('%010.2e', 1.0/3.0))
! call assert_equal(' 03
Re: Small doc fixes for lambda
Ken Takata wrote: > 2016/8/29 Mon 4:21:51 UTC+9 Bram Moolenaar wrote: > > Manuel Ortega wrote: > > > > > At ":h lambda", there is some erroneous markup. It mistakenly is > > > "|expr1|", which takes the user to the help for the ternary conditional! > > > > That is correct. This is the higest level expression. It's clearer if > > you start with reading ":help expression-syntax". > > I think I found some mistakes in ":help expression-syntax". > Please check the attached patch. Misalignment is also fixed. Hmm, some things were correct. For example: |expr7| ! expr7 logical NOT - expr7 unary minus + expr7 unary plus This means you can use !!expr7, !-!expr7, etc. It doesn't mention that expr7 can be expr8, that applies to all of them. Does it help to add them anyway? Like this: |expr7| expr8 ! expr7 logical NOT - expr7 unary minus + expr7 unary plus -- hundred-and-one symptoms of being an internet addict: 100. The most exciting sporting events you noticed during summer 1996 was Netscape vs. Microsoft. /// 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: Diff should indicate if no differences detected
John Beckett wrote: > On Sunday, August 28, 2016 at 10:40:05 PM UTC+10, Bram Moolenaar wrote: > > John Beckett wrote: > >> It is a real problem that Vim can mislead the user into thinking there > >> is no difference, when in fact a new line has been inserted at the top > >> of the other window. Just scrolling one window to the top is not > >> enough because unless you gg in *both* windows, you have no idea > >> whether the files are identical or not. > > > > It's strange that in this case we get lots of useless "~" lines. > > I wonder why that happens. Probably the top line in the window is > > computed before the fold is closed. > > > > At least it helps a bit to set 'scrolloff' to 5 or more. > > Hmm, perhaps we should add that to the defaults. > > Thanks Bram for patch 7.4.2279, that's much better. > However, the following shows there is still a frustration. > > Using gvim.exe 7.4.2290 > > Start Vim then execute the commands shown. > > gvim -N -u NONE > > :let lines = range(1, 999) > :call writefile(lines, 'old.tmp') > :call writefile(['inserted'] + lines, 'new.tmp') > :e new.tmp > :vert diffs old.tmp > > One way to execute the commands is to copy the lines to the > clipboard. In Vim, type @+ > > Result: See two windows side-by-side. They appear to be > identical, with each window showing: > > 1 > 2 > 3 > 4 > 5 > 6 > +--993 lines: 7-- > > The cursor is on "1" at the top of the left-hand window. > Pressing [c does nothing other than ring the bell. The only way > I know to see that the two files are different is to switch to > the right-hand window and scroll up ([c works). > > I'm never confident any more that a diff is showing everything. For me, when the files are identical I would not see any lines of text, only the closed fold. Perhaps your setting is to always open the fold under the cursor? That filler lines may hide above the window is hard to avoid. We can't disallow scrolling the window into that position. Scrolling one line down to reveal one filler line is not so easy in general, would only work in some situations. E.g. when the line wraps in the other window it may completely fill the window and the cursor line can't be displayed. -- Contrary to popular belief, Unix is user friendly. It just happens to be selective about who it makes friends with. -- Dave Parnas /// 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: make report fails in testdir at v7.4.2290
Elimar Riesebieter wrote: > $ make report > > Test results: > > > >From test_alot.vim: > Found errors in Test_tabpage_with_tab_modifier(): > function RunTheTest[9]..Test_tabpage_with_tab_modifier[13]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[14]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[15]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[16]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[17]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[18]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[19]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[20]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[21]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[22]..40_check_tab > line 4: Expected 'help' but got 'text' > TEST FAILURE > Makefile:41: recipe for target 'report' failed > make: *** [report] Error 1 Works for me and I assume most others. What is special about your setup? How did you get the sources? -- hundred-and-one symptoms of being an internet addict: 102. When filling out your driver's license application, you give your IP address. /// 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: system() delay
Ramel Eshed wrote:
> On Sunday, August 28, 2016 at 11:36:33 PM UTC+3, Bram Moolenaar wrote:
> > Ramel Eshed wrote:
> >
> > > Of course, I've measured the time from job_start to close_cb. You can see
> > > this comparison in the example I've attached earlier in this thread.
> >
> > Hmm, it's possible that detecting that the other end closed the pipe
> > happens much sooner than detecting that the child process has ended.
> > If that is the case I don't think there is a way around that.
> >
> >
> > --
> > hundred-and-one symptoms of being an internet addict:
> > 96. On Super Bowl Sunday, you followed the score by going to the
> > Yahoo main page instead of turning on the TV.
> >
> > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> > \\\ an exciting new programming language -- http://www.Zimbu.org///
> > \\\help me help AIDS victims -- http://ICCF-Holland.org///
>
> Well, I didn't think something like this could work but it did:
>
> func! System(cmd)
> let out = []
> let job = job_start(['/bin/sh', '-c', a:cmd],
> \ {'out_cb': {c, msg -> add(out, msg)}})
> let ch = job_getchannel(job)
> while ch_status(ch) != 'closed'
> sleep 10m
> endwhile
> return out
> endfunc
>
> Maybe it should be done the same way in the C system() implementation...
This requires more investigation. There is also code to still read from
the pipe after the child process exits, thus it is possible that not
being able to read is sufficient to stop waiting for the child. Except
when we want the exit code.
--
hundred-and-one symptoms of being an internet addict:
99. The hum of a cooling fan and the click of keys is comforting to you.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: bug with folding
Christian Brabandt wrote: > I am currently writing some tests for normal.c, to increase the coverage. > > Unfortunately, I noteiced some bugs with folding: Here is one issue: > > ~$ vim -u NONE -N > call setline(1, range(1,10) > :3 > norm! 2zF > :2 > norm! 5zF > :set nofoldenable > :3 > norm! zc -> folds line 2 - 8, I would have expected to only close the inner > fold 3-4, but perhaps that is expected, but see below: > set nofoldenable > norm! Vzc -> correctly folds 3-4 > :set nofoldenable > norm! zc -> folds lines 3-4? Isn't this because 'foldlevel' keeps the same value when 'foldenable' is reset? > Also I got another session, where zF create one additional closing > fold marker several lines below where it definitly shouldn't. > Unfortunately, I can't reproduce this problem anymore. The rules for opening a closing folds are a bit complicated... It's possible there is a bug, but it's also possible that something is missing in the documentation. I notice "zc" doesn't say anything about 'foldlevel'. -- hundred-and-one symptoms of being an internet addict: 97. Your mother tells you to remember something, and you look for a File/Save command. /// 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] Ignore comments when jumping to a declaration
Anton Lindqvist wrote:
> The goto declaration commands (gd and gD) only discards completely
> commented out lines. In the following scenario pressing 'gd' would place
> the cursor on the occurrence of x inside the trailing comment:
>
> int func(int x) /* x is an int */
> {
> return x;
> ^
> |
> cursor
> }
>
> This is by design, the search is not terminated at the first occurrence
> of the identifier in order to handle K&R function declarations
> correctly.
>
> The attached patch add support for discarding any type of C-style
> comment. Thus, it does not respect the commentstring option. I think
> this is reasonable since the behavior of gd and gD is tailored for C
> code but occasionally works well with other similar languages. Another
> limitation of the attached patch is that it does not recognize nested
> multi-line comments (/* /* nested */ */) but should one care?
>
> While at it, improve the test coverage for both gd and gD.
Thanks, I'll add it in the todo list.
--
hundred-and-one symptoms of being an internet addict:
104. When people ask about the Presidential Election you ask "Which country?"
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] corrections in runtime/doc/version8.txt
Dominique wrote: > Attached patch contains minor corrections to > runtime/doc/version8.txt. Thanks. -- A meeting is an event at which the minutes are kept and the hours are lost. /// 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.
Will the default 8-bit meta mode in vim conflict with utf-8 characters in terminal ?
As ':help :map-alt-keys': By default Vim assumes that pressing the ALT key sets the 8th bit of a typed character. Most decent terminals can work that way, such as xterm, aterm and rxvt. If your mappings don't work it might be that the terminal is prefixing the character with an ESC character. But you can just as well type ESC before a character, thus Vim doesn't know what happened (except for checking the delay between characters, which is not reliable). As of this writing, some mainstream terminals like gnome-terminal and konsole use the ESC prefix. There doesn't appear a way to have them use the 8th bit instead. Xterm should work well by default. Aterm and rxvt should work well when started with the "--meta8" argument. You can also tweak resources like "metaSendsEscape", "eightBitInput" and "eightBitOutput". - in the modern terminals (like iTerm / gnome-terminal), typing unicode characters will be encoded as utf-8 and transfer to vim, which may contains the 8th bit. Will vim recognize utf-8 data stream as some meta-* key strokes ? Should I always set - to ^[a - ^[z in terminal to avoid that mistake ? -- -- 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] Vim cryptmethod is not authenticated (#638)
Hi Charles! On Mo, 29 Aug 2016, Charles E Campbell wrote: > P.S. As a tech thing, its likely that quantum computers will break all > the crypto in a decade or two. Yeah, that is what they have been telling us for the last 20 years... Best, Christian -- Auch die geistreichen Menschen suchen - sobald sie einander nur einige Male zuerst gesehen - dann mehr die Bücher als deren Verfasser. -- Jean Paul -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Vim cryptmethod is not authenticated (#638)
Marvin Renich wrote: > Bugs in Vim's encryption algorithms should, of course, be fixed if > possible, but not in a way that prevents access to older encrypted > data files. That includes keeping, for a significant amount of time > (two years? I'm not sure how long), the ability to write files that > can be read by older versions of Vim. Requiring a confirmation when > using a deprecated algorithm is certainly reasonable. ...Marvin We seem to encounter folks with vims that are out of date by at least 6 years (v7.3 - I had a bug report recently from a vim v7.3 user, for example). It wouldn't surprise me at all to find that there are 7.1 and 7.2 users out there (7.1 dates from 2007). Regards, Chip Campbell P.S. As a tech thing, its likely that quantum computers will break all the crypto in a decade or two. -- -- 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: Write block of raw text
2016-08-29 15:41 GMT+03:00 Luc Hermitte : > Hi, > > >> > Is there a command somewhere to put or let block of raw lines in >> > VimL. >> >> To "put" you could use: >> insert >> line 1 >> line 2 >> Line 3 >> . > > Thanks. I forgot about this one. > > I'll see after the v8 release if we could have something similar to feed into > :let or may be other commands. Why? I know only one language which has this feature - perl - others usually have some sort of multiline strings (if they have something at all). I would welcome Python-like line continuation (to continue line you need unclosed parenthesis, bracket or figure brace) and some kind of multiline strings accepted by evalN (making any of these work requires basically the same changes: in first place, passing down fgetline+cookie pair like the one accepted by do_one_cmd()), but not Perl-like < > -- > Luc Hermitte > > -- > -- > 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. -- -- 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] Excessive dedent on split ELSE IF in Fortran (#1020)
On Monday, August 29, 2016 at 2:45:54 AM UTC-3, naught101 wrote: > Indenting using gg=G on this program works: [snip] > but if the last logical expression is split into two lines, then the indenter > chokes and dedents the second part of the line and all of the following parts > of the code by one level: This has now been fixed. I'll send the updates to Bram. If you want to give the revised indent file a whirl immediately, please email me (Ajit Thakkar) directly. My email address can be found in the distributed indent file. Ajit -- -- 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] Vim cryptmethod is not authenticated (#638)
* Ben Fritz [160826 18:05]: > Well, here's the sort of thing I worry about the most far most users: > > http://www.vim.org/scripts/script.php?script_id=5340 > http://usevim.com/2013/11/27/password-manager/ > https://invert.svbtle.com/using-vim-as-a-password-manager > https://stelfox.net/blog/2013/11/using-vim-as-your-password-manager/ > http://vim.wikia.com/wiki/Keep_passwords_in_encrypted_file > > And then of course somebody could get the bright idea of encrypting a > 20GB CSV file of medical data to put on a flash drive or something. > > I'd hope dissidents and the like use tools more designed for the task already. I'm not sure whether you are agreeing or disagreeing with me. Here is a summary of my POV: • The encryption algorithm used by Vim used to be considered strong, but is now considered weak. • Newer, stronger encryption should be added to Vim. (Hopefully with a well thought out plan that allows adding new encryption algorithms without recompiling Vim.) • Removing Vim's existing encryption does not help users who currently use it, even though it is weak. If you are simply pointing out that some people believe Vim is the right tool for some cryptographic applications, I certainly agree with that. If you are saying that we should remove Vim's current algorithm because some people are using it without realizing that it is no longer considered as strong as it use to be, I strongly disagree. The help file should document this concern, and if the script and blog authors wish to make it more obvious to users, that is good, too. My soapbox statement really boils down to two points: • Known-weak encryption has valid uses. • The idea that an encryption algorithm that used to be considered strong must always be removed soon after it is decided that it is weak is wrong. The second point is, in my opinion, especially true in the case of Vim at the moment, because there is no alternative. However, even when a better algorithm is added to Vim, there are bound to be many files out there that are already encrypted using the older algorithm. We should not require users to keep an old version of Vim just to be able to read those files. Bugs in Vim's encryption algorithms should, of course, be fixed if possible, but not in a way that prevents access to older encrypted data files. That includes keeping, for a significant amount of time (two years? I'm not sure how long), the ability to write files that can be read by older versions of Vim. Requiring a confirmation when using a deprecated algorithm is certainly reasonable. ...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: check for sandbox in viml?
Hi Bram! On Fr, 26 Aug 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > > > now that we have the async and timer feature, wouldn't it make sense to > > > > have a way to check, whether Vim is in sandbox mode, so that some > > > > functions don't randomly trigger E48 errors and can check, whether it > > > > is > > > > okay to be executed? > > > > > > It would be easy to add a function for this. But before we do, can you > > > give an example of how it would be used? > > > > Well, I use a plugin for sporadically saving unsaved buffers. This uses > > the new timers functionality and internally uses bufdo to run over all > > buffers. Now unfortunately this was triggered once I debugged a Vim > > script (so the sandbox was active). > > > > Now I could of course use :try/catch, but I rather like to avoid doing > > anything, if I am in the sandbox. But perhaps, I should instead switch > > to using writefile() and bufnr() instead of using :bufdo :w > > Well, it won't hurt to have a sandbox() function. Ah, nevermind. After thinking some more, it might be useful, but I don't think I desperate need it anymore. So the current state is okay for me. Best, Christian -- Wer viel arbeitet macht viele Fehler, wer keine Fehler macht wird prämiert. -- -- 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] mention skipped tests for new_style tests
Hi,
while working on some more tests, I noticed some bugs. I will report
them separately, whenever I have a test, that is reproducible
stand-alone, but until then, I like to disable some tests (and don't
forget about them).
However, it would be nice, if the logfile could mention, if a test has
been skipped, and which one.
Therefore here is a patch, that adds this ability. See the commit
message for an detailed explanation.
Best,
Christian
--
Sobald man das Nicht-reden-wollen ausspricht, tut man es ja doch.
-- Freddy Leitner
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From 435f71420b03a238b05e4e6a5cf5a79954149ab2 Mon Sep 17 00:00:00 2001
From: Christian Brabandt
Date: Mon, 29 Aug 2016 11:06:21 +0200
Subject: [PATCH 1/2] Mention the number of skipped tests
Sometimes tests have to be commented, either
because it is not clear how a bug has to be fixed
or because it is not clear, if there is a bug at all.
Therefore, instead of silently skip a test, at least
mention, if a test was skipped.
To do so, one has to explicitly set the g:skipped_test variable
from within your test to the name of the test, that was skipped.
An example looks like this:
" currently disabled
" fails currently
call add(g:skipped_test, 'zc_command in: '. matchstr(expand(''), '.*\.\.\zs[^.]*\ze$'))
" now follows the commented test:
"norm! zc
"call assert_equal(1, &foldenable)
"norm! k
That will output something like this:
From test_normal.vim:
Executing Test_normal01_keymodel()
Executing Test_normal02_selectmode()
Executing Test_normal03_join()
Executing Test_normal04_filter()
Executing Test_normal05_formatexpr()
Executing Test_normal06_formatprg()
Executing Test_normal07_internalfmt()
Executing Test_normal08_fold()
Executing Test_normal09_operatorfunc()
Executing Test_normal10_expand()
Executing Test_normal11_showcmd()
Executing Test_normal12_nv_error()
Executing Test_normal13_help()
Executing Test_normal14_page()
Executing Test_normal15_z_scroll_vert()
Executing Test_normal16_z_scroll_hor()
Executing Test_normal17_z_scroll_hor()
Executing Test_normal18_z_fold()
Executed 18 tests
From test_normal.vim:
Skipped 1 test: zc_command in: Test_normal18_z_fold
Also change test_popup.vim to report, which test was skipped
---
src/testdir/runtest.vim| 6 ++
src/testdir/test_popup.vim | 3 +++
2 files changed, 9 insertions(+)
diff --git a/src/testdir/runtest.vim b/src/testdir/runtest.vim
index 2660d93..19a2901 100644
--- a/src/testdir/runtest.vim
+++ b/src/testdir/runtest.vim
@@ -127,6 +127,7 @@ let s:done = 0
let s:fail = 0
let s:errors = []
let s:messages = []
+let g:skipped_test = [] " number of tests skipped, needs to be set explicitly
if expand('%') =~ 'test_viml.vim'
" this test has intentional s:errors, don't use try/catch.
source %
@@ -156,11 +157,13 @@ endif
" Execute the tests in alphabetical order.
for s:test in sort(s:tests)
+ let g:skipped_test = []
call RunTheTest(s:test)
if len(v:errors) > 0 && index(s:flaky, s:test) >= 0
call add(s:messages, 'Flaky test failed, running it again')
let v:errors = []
+let g:skipped_test = []
call RunTheTest(s:test)
endif
@@ -170,6 +173,9 @@ for s:test in sort(s:tests)
call extend(s:errors, v:errors)
let v:errors = []
endif
+ if len(g:skipped_test) > 0
+call add(s:errors, printf('Skipped %d %s: %s', len(g:skipped_test), len(g:skipped_test) > 1 ? 'tests' : 'test', join(g:skipped_test, ' ')))
+ endif
endfor
" Don't write viminfo on exit.
diff --git a/src/testdir/test_popup.vim b/src/testdir/test_popup.vim
index 34a2251..0460bd8 100644
--- a/src/testdir/test_popup.vim
+++ b/src/testdir/test_popup.vim
@@ -171,6 +171,9 @@ func! Test_popup_complete()
" Insert match immediately, if there is only one match
" Should select a character from the line below
" TODO: test disabled because the code change has been reverted.
+ " Disabled in Patch 7.4.2188
+ call add(g:skipped_test, '_popupmenu in: '. matchstr(expand(''), '.*\.\.\zs[^.]*\ze$'))
+
" call append(1, ["December2015"])
" :1
" call feedkeys("aD\\\", 'tx')
--
2.1.4
Re: Write block of raw text
Hi, > > Is there a command somewhere to put or let block of raw lines in > > VimL. > > To "put" you could use: > insert > line 1 > line 2 > Line 3 > . Thanks. I forgot about this one. I'll see after the v8 release if we could have something similar to feed into :let or may be other commands. -- Luc Hermitte -- -- 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: Diff should indicate if no differences detected
On Sunday, August 28, 2016 at 10:40:05 PM UTC+10, Bram Moolenaar wrote: > John Beckett wrote: >> It is a real problem that Vim can mislead the user into thinking there >> is no difference, when in fact a new line has been inserted at the top >> of the other window. Just scrolling one window to the top is not >> enough because unless you gg in *both* windows, you have no idea >> whether the files are identical or not. > > It's strange that in this case we get lots of useless "~" lines. > I wonder why that happens. Probably the top line in the window is > computed before the fold is closed. > > At least it helps a bit to set 'scrolloff' to 5 or more. > Hmm, perhaps we should add that to the defaults. Thanks Bram for patch 7.4.2279, that's much better. However, the following shows there is still a frustration. Using gvim.exe 7.4.2290 Start Vim then execute the commands shown. gvim -N -u NONE :let lines = range(1, 999) :call writefile(lines, 'old.tmp') :call writefile(['inserted'] + lines, 'new.tmp') :e new.tmp :vert diffs old.tmp One way to execute the commands is to copy the lines to the clipboard. In Vim, type @+ Result: See two windows side-by-side. They appear to be identical, with each window showing: 1 2 3 4 5 6 +--993 lines: 7-- The cursor is on "1" at the top of the left-hand window. Pressing [c does nothing other than ring the bell. The only way I know to see that the two files are different is to switch to the right-hand window and scroll up ([c works). I'm never confident any more that a diff is showing everything. John -- -- 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: make report fails in testdir at v7.4.2290
Elimar Riesebieter wrote: > * Dominique Pellé [2016-08-29 09:21 +0200]: > >> Elimar Riesebieter wrote: >> >> > $ make report >> > >> > Test results: >> > >> > >> > From test_alot.vim: >> > Found errors in Test_tabpage_with_tab_modifier(): >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[13]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[14]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[15]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[16]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[17]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[18]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[19]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[20]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[21]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > function >> > RunTheTest[9]..Test_tabpage_with_tab_modifier[22]..40_check_tab line >> > 4: Expected 'help' but got 'text' >> > TEST FAILURE >> > Makefile:41: recipe for target 'report' failed >> > make: *** [report] Error 1 >> > >> > Elimar >> >> Just a guess: could it be that the test relies on having previously done >> "make install" to find help files and you have not run "make install" >> before running the tests? >> >> If that's the case, it's a problem with tests, as I don't think that tests >> should rely on "make install". The proper order should be something >> like this: >> >> $ cd vim >> $ rm src/auto/config.cache >> $ ./configure --with-features=huge --enable-gui=gtk3 >> $ make -j4 >> $ make test >> $ sudo make install # if all tests passed > > The tests are fired up before make install and after make. The > tests are running in a shadowdir. > > Thanks for investigation Right. And the tests pass if I delete /us/local/share/vim so replying on "make install" is not the problem here. I can't reproduce it so I don't know what happens here. Dominique -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
bug with folding
Bram, I am currently writing some tests for normal.c, to increase the coverage. Unfortunately, I noteiced some bugs with folding: Here is one issue: ~$ vim -u NONE -N call setline(1, range(1,10) :3 norm! 2zF :2 norm! 5zF :set nofoldenable :3 norm! zc -> folds line 2 - 8, I would have expected to only close the inner fold 3-4, but perhaps that is expected, but see below: set nofoldenable norm! Vzc -> correctly folds 3-4 :set nofoldenable norm! zc -> folds lines 3-4? Also I got another session, where zF create one additional closing fold marker several lines below where it definitly shouldn't. Unfortunately, I can't reproduce this problem anymore. Best, Christian -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: make report fails in testdir at v7.4.2290
* Dominique Pellé [2016-08-29 09:21 +0200]: > Elimar Riesebieter wrote: > > > $ make report > > > > Test results: > > > > > > From test_alot.vim: > > Found errors in Test_tabpage_with_tab_modifier(): > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[13]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[14]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[15]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[16]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[17]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[18]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[19]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[20]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[21]..40_check_tab line > > 4: Expected 'help' but got 'text' > > function > > RunTheTest[9]..Test_tabpage_with_tab_modifier[22]..40_check_tab line > > 4: Expected 'help' but got 'text' > > TEST FAILURE > > Makefile:41: recipe for target 'report' failed > > make: *** [report] Error 1 > > > > Elimar > > Just a guess: could it be that the test relies on having previously done > "make install" to find help files and you have not run "make install" > before running the tests? > > If that's the case, it's a problem with tests, as I don't think that tests > should rely on "make install". The proper order should be something > like this: > > $ cd vim > $ rm src/auto/config.cache > $ ./configure --with-features=huge --enable-gui=gtk3 > $ make -j4 > $ make test > $ sudo make install # if all tests passed The tests are fired up before make install and after make. The tests are running in a shadowdir. Thanks for investigation Elimar -- >what IMHO then? IMHO - Inhalation of a Multi-leafed Herbal Opiate ;) --posting from alex in debian-user-- -- -- 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: make report fails in testdir at v7.4.2290
Elimar Riesebieter wrote: > $ make report > > Test results: > > > From test_alot.vim: > Found errors in Test_tabpage_with_tab_modifier(): > function RunTheTest[9]..Test_tabpage_with_tab_modifier[13]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[14]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[15]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[16]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[17]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[18]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[19]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[20]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[21]..40_check_tab > line 4: Expected 'help' but got 'text' > function RunTheTest[9]..Test_tabpage_with_tab_modifier[22]..40_check_tab > line 4: Expected 'help' but got 'text' > TEST FAILURE > Makefile:41: recipe for target 'report' failed > make: *** [report] Error 1 > > Elimar Just a guess: could it be that the test relies on having previously done "make install" to find help files and you have not run "make install" before running the tests? If that's the case, it's a problem with tests, as I don't think that tests should rely on "make install". The proper order should be something like this: $ cd vim $ rm src/auto/config.cache $ ./configure --with-features=huge --enable-gui=gtk3 $ make -j4 $ make test $ sudo make install # if all tests passed 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.
