Re: more testing questions
On Di, 23 Apr 2019, tooth pik wrote: > it occurs to me to ask if testing is supposed to succeed if you run it > in its own xterm -- > i do that so as not to mess up any of my konsole tabs > > my xterm reports it is version X.Org 7.7.0(308) which is current for > my opensuse Leap 4.3 > > nothing else was running from vim (except a gvim with a hidden buffer > displaying a calendar) so "parallel" shouldn't be relevant > > it failed several ways this time, none i think the same as the last > time -- i will attach a paste from the failures... You got one failure when testing the clipboard support. I guess your vim is not able to connect to your X11 system or something like that. The others are failures from the dump test. Have a look at the mentioned term_dumpdiff() command and see if you can infer from inspecting the dump, why it failed. See also `:h term_dumpdiff()` Best, Christian -- Männer würden Frauen gern das letzte Wort lassen, wenn sie sicher sein könnten, daß es wirklich das letzte ist. -- -- 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.
more testing questions
it occurs to me to ask if testing is supposed to succeed if you run it in its own xterm -- i do that so as not to mess up any of my konsole tabs my xterm reports it is version X.Org 7.7.0(308) which is current for my opensuse Leap 4.3 nothing else was running from vim (except a gvim with a hidden buffer displaying a calendar) so "parallel" shouldn't be relevant it failed several ways this time, none i think the same as the last time -- i will attach a paste from the failures... -- -- 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. testfailure Description: Binary data
Patch 8.1.1200
Patch 8.1.1200
Problem:Old style comments in debugger source.
Solution: Use new style comments. (Yegappan Lakshmanan, closes #4286)
Files: src/README.md, src/debugger.c
*** ../vim-8.1.1199/src/README.md 2019-03-31 15:31:54.592053004 +0200
--- src/README.md 2019-04-23 18:36:55.603847919 +0200
***
*** 25,30
--- 25,31
- | ---
autocmd.c | autocommands
buffer.c | manipulating buffers (loaded files)
+ debugger.c| vim script debugger
diff.c| diff mode (vimdiff)
eval.c| expression evaluation
fileio.c | reading and writing files
*** ../vim-8.1.1199/src/debugger.c 2019-04-21 11:34:36.335256531 +0200
--- src/debugger.c 2019-04-23 18:36:55.603847919 +0200
***
*** 14,28
#include "vim.h"
#if defined(FEAT_EVAL) || defined(PROTO)
! static int debug_greedy = FALSE; /* batch mode debugging: don't save
! and restore typeahead. */
static void do_setdebugtracelevel(char_u *arg);
static void do_checkbacktracelevel(void);
static void do_showbacktrace(char_u *cmd);
! static char_u *debug_oldval = NULL; /* old and newval for debug expressions
*/
static char_u *debug_newval = NULL;
! static int debug_expr = 0;/* use debug_expr */
int
has_watchexpr(void)
--- 14,28
#include "vim.h"
#if defined(FEAT_EVAL) || defined(PROTO)
! static int debug_greedy = FALSE; // batch mode debugging: don't save
! // and restore typeahead.
static void do_setdebugtracelevel(char_u *arg);
static void do_checkbacktracelevel(void);
static void do_showbacktrace(char_u *cmd);
! static char_u *debug_oldval = NULL; // old and newval for debug expressions
static char_u *debug_newval = NULL;
! static int debug_expr = 0;// use debug_expr
int
has_watchexpr(void)
***
*** 65,91
#define CMD_DOWN 10
#ifdef ALWAYS_USE_GUI
! /* Can't do this when there is no terminal for input/output. */
if (!gui.in_use)
{
! /* Break as soon as possible. */
debug_break_level = ;
return;
}
#endif
! /* Make sure we are in raw mode and start termcap mode. Might have side
! * effects... */
settmode(TMODE_RAW);
starttermcap();
! ++RedrawingDisabled; /* don't redisplay the window */
! ++no_wait_return; /* don't wait for return */
! did_emsg = FALSE; /* don't use error from debugged stuff */
! cmd_silent = FALSE; /* display commands */
! msg_silent = FALSE; /* display messages */
! emsg_silent = FALSE; /* display error messages */
! redir_off = TRUE; /* don't redirect debug commands */
State = NORMAL;
debug_mode = TRUE;
--- 65,91
#define CMD_DOWN 10
#ifdef ALWAYS_USE_GUI
! // Can't do this when there is no terminal for input/output.
if (!gui.in_use)
{
! // Break as soon as possible.
debug_break_level = ;
return;
}
#endif
! // Make sure we are in raw mode and start termcap mode. Might have side
! // effects...
settmode(TMODE_RAW);
starttermcap();
! ++RedrawingDisabled; // don't redisplay the window
! ++no_wait_return; // don't wait for return
! did_emsg = FALSE; // don't use error from debugged stuff
! cmd_silent = FALSE; // display commands
! msg_silent = FALSE; // display messages
! emsg_silent = FALSE; // display error messages
! redir_off = TRUE; // don't redirect debug commands
State = NORMAL;
debug_mode = TRUE;
***
*** 110,128
smsg(_("line %ld: %s"), (long)sourcing_lnum, cmd);
else
smsg(_("cmd: %s"), cmd);
! /*
! * Repeat getting a command and executing it.
! */
for (;;)
{
msg_scroll = TRUE;
need_wait_return = FALSE;
! /* Save the current typeahead buffer and replace it with an empty one.
!* This makes sure we get input from the user here and don't interfere
!* with the commands being executed. Reset "ex_normal_busy" to avoid
!* the side effects of using ":normal". Save the stuff buffer and make
!* it empty. Set ignore_script to avoid reading from script input. */
save_ex_normal_busy = ex_normal_busy;
ex_normal_busy = 0;
if (!debug_greedy)
--- 110,127
smsg(_("line %ld: %s"), (long)sourcing_lnum, cmd);
else
smsg(_("cmd: %s"), cmd);
!
! // Repeat getting a command and executing it.
for (;;)
{
msg_scroll = TRUE;
need_wait_return = FALSE;
! // Save the current typeahead buffer and replace it with an empty one.
! // This makes sure we get inp
Re: [vim/vim] win32: Reimplementation of VIMDLL (#4287)
Ken Takata wrote:
> The VIMDLL support was removed at
> [8.1.1066](https://github.com/vim/vim/commit/89828e9fe6de4d70e0e2ccd3c711bd26632c26a9).
> I reimplemented it on MSVC and MinGW.
> The differences from the old implementation are:
>
> * Supports MSVC and MinGW. (Don't support Borland C++.)
> * Supports gvim.exe and vim.exe.
> If you build with `nmake -f Make_mvc.mak VIMDLL=yes`, vim{32,64}.dll
> will be built and also stub gvim.exe and vim.exe will be built.
> The shared codes between GUI and CUI are all built into the DLL.
> So the total size of the distribution files can be reduced.
Sounds good so far.
> * Supports `vim -g` and the `:gui` commands.
> If the commands are executed with the `-f` option, vim.exe will open a GUI
> window directly. Otherwise, vim.exe will execute gvim.exe. `:gui` will
> use `:mksession` to inherit the session to gvim.exe.
Does this really work? Any variable values would be lost.
--
I have to exercise early in the morning before my brain
figures out what I'm doing.
/// 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.1.1199
Patch 8.1.1199
Problem:No test for :abclear.
Solution: Add a test. (Dominique Pelle, closes #4292)
Files: src/testdir/test_mapping.vim
*** ../vim-8.1.1198/src/testdir/test_mapping.vim2019-03-26
22:46:01.885928372 +0100
--- src/testdir/test_mapping.vim2019-04-23 16:33:42.161016524 +0200
***
*** 11,16
--- 11,72
set nomodified
endfunc
+ func Test_abclear()
+abbrev foo foobar
+iabbrev fooi foobari
+cabbrev fooc foobarc
+call assert_equal("\n\n"
+ \.. "c fooc foobarc\n"
+ \.. "i fooi foobari\n"
+ \.. "! foo foobar", execute('abbrev'))
+
+iabclear
+call assert_equal("\n\n"
+ \.. "c fooc foobarc\n"
+ \.. "c foo foobar", execute('abbrev'))
+abbrev foo foobar
+iabbrev fooi foobari
+
+cabclear
+call assert_equal("\n\n"
+ \.. "i fooi foobari\n"
+ \.. "i foo foobar", execute('abbrev'))
+abbrev foo foobar
+cabbrev fooc foobarc
+
+abclear
+call assert_equal("\n\nNo abbreviation found", execute('abbrev'))
+ endfunc
+
+ func Test_abclear_buffer()
+ abbrev foo foobar
+ new X1
+ abbrev foo1 foobar1
+ new X2
+ abbrev foo2 foobar2
+
+ call assert_equal("\n\n"
+ \.. "! foo2 @foobar2\n"
+ \.. "! foo foobar", execute('abbrev'))
+
+ abclear
+ call assert_equal("\n\n"
+ \.. "! foo foobar", execute('abbrev'))
+
+ b X1
+ call assert_equal("\n\n"
+ \.. "! foo1 @foobar1\n"
+ \.. "! foo foobar", execute('abbrev'))
+ abclear
+ call assert_equal("\n\n"
+ \.. "! foo foobar", execute('abbrev'))
+
+ abclear
+call assert_equal("\n\nNo abbreviation found", execute('abbrev'))
+
+ %bwipe
+ endfunc
+
func Test_map_ctrl_c_insert()
" mapping of ctrl-c in Insert mode
set cpo-=< cpo-=k
*** ../vim-8.1.1198/src/version.c 2019-04-21 17:22:29.749014298 +0200
--- src/version.c 2019-04-23 16:35:21.476465071 +0200
***
*** 773,774
--- 773,776
{ /* Add new patch number below this line */
+ /**/
+ 1199,
/**/
--
Not too long ago, a program was something you watched on 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///
--
--
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: Why does the text property development suspended
Wei Zhang wrote: > No update for 4 month, do we have any difficulty that can't be overcame ? > > Does it need a big refactor ?? Anything the community can help ?? I have been including a lot of pending patches. I feel that people who take the effort to write a useful patch should be "rewarded" by including their work. Also because letting them sit for a while often causes merge problems. You are the first since a long time to ask about text properties. That's why I haven't given it more time recently. I do intent to pick it up soon, especially because it's blocking other work, such as the floating windows (for which there is a design discussion going on). -- You were lucky. We lived for three months in a brown paper bag in a septic tank. We used to have to get up at six o'clock in the morning, clean the bag, eat a crust of stale bread, go to work down mill for fourteen hours a day week in-week out. When we got home, our Dad would thrash us to sleep with his belt! /// 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: idle question about testing
> is "make test" supposed to work currently? i can't remember the last > time i didn't get a failed somethingorother from it > > this time it's errors in Test_incsearch_substitute_dump() > > i don't run make test very often so I'm curious -- are tests supposed > to succeed? Yes. But, as mentioned, not in parallel, perhaps that is your problem? -- Yah, well, we had to carve our electrons out of driftwood we'd find. In the winter. Uphill. Both ways. /// 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: idle question about testing
Dominique wrote: > Christian Brabandt wrote: > > > On Di, 23 Apr 2019, tooth pik wrote: > > > > > is "make test" supposed to work currently? i can't remember the last > > > time i didn't > > > get a failed somethingorother from it > > > > > > this time it's errors in Test_incsearch_substitute_dump() > > > > > > i don't run make test very often so I'm curious -- are tests supposed > > > to succeed? > > > > Yes the test suite is supposed to be comleted successfully and I don't > > remember a breakage for a longer time (exceptions being new patches > > temporarily breaking it, but those problems have been fixed very soon by > > Bram). > > > > If you encounter a failing test, please show the log of it. > > Is that really true? I always build Vim in parallel > with "make -j8" but I never run tests in parallel. It > would certainly be nice if tests could be run in > parallel, but at the moment it does not seem safe. > > Here for example I see 2 tests writing the same file > name "Xtest1" which prevents running tests safely > in parallel. I'm almost sure that there are other cases > like this: > > $ cd vim/src > $ grep "writefile(.*'Xtest1'" *.vim > test_swap.vim: call writefile(content, 'Xtest1') > test_winbuf_close.vim: call writefile(['testtext 1'], 'Xtest1') In the beginning some temp files were indeed using a common name. Since a while I have started to use more unique names, but there is no check for that. Also, there is no good check for cleaning up. It should definitely be possible to add some script for this. Either by defining a command to create the file, a specific comment (although that would be easy to miss), or check for delete() calls. The make a list with unique file names per test, append them to a file, and have a final test check for duplicates and leftover files. -- You were lucky to have a LAKE! There were a hundred and sixty of us living in a small shoebox in the middle of the road. /// 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: idle question about testing
On Di, 23 Apr 2019, Dominique Pellé wrote: > Is that really true? I always build Vim in parallel > with "make -j8" but I never run tests in parallel. It > would certainly be nice if tests could be run in > parallel, but at the moment it does not seem safe. Indeed, I think parallel execution of tests is not supported yet. Best, Christian -- Ich kann Küssen nicht leiden, wenn ich nicht dabei bin. -- -- 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: idle question about testing
On Tue, Apr 23, 2019 at 11:48 AM Dominique Pellé wrote: > > Christian Brabandt wrote: > > > On Di, 23 Apr 2019, tooth pik wrote: > > > > > is "make test" supposed to work currently? i can't remember the last > > > time i didn't > > > get a failed somethingorother from it > > > > > > this time it's errors in Test_incsearch_substitute_dump() > > > > > > i don't run make test very often so I'm curious -- are tests supposed > > > to succeed? > > > > Yes the test suite is supposed to be comleted successfully and I don't > > remember a breakage for a longer time (exceptions being new patches > > temporarily breaking it, but those problems have been fixed very soon by > > Bram). > > > > If you encounter a failing test, please show the log of it. > > Is that really true? I always build Vim in parallel > with "make -j8" but I never run tests in parallel. It > would certainly be nice if tests could be run in > parallel, but at the moment it does not seem safe. > > Here for example I see 2 tests writing the same file > name "Xtest1" which prevents running tests safely > in parallel. I'm almost sure that there are other cases > like this: > > $ cd vim/src > $ grep "writefile(.*'Xtest1'" *.vim > test_swap.vim: call writefile(content, 'Xtest1') > test_winbuf_close.vim: call writefile(['testtext 1'], 'Xtest1') > > Dominique > Maybe the tests should write, not files with generic names like "Xtest1" but files with names related to the test name, e.g., Xswap1, Xwinbuf_close1, etc.? 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: idle question about testing
Christian Brabandt wrote: > On Di, 23 Apr 2019, tooth pik wrote: > > > is "make test" supposed to work currently? i can't remember the last > > time i didn't > > get a failed somethingorother from it > > > > this time it's errors in Test_incsearch_substitute_dump() > > > > i don't run make test very often so I'm curious -- are tests supposed > > to succeed? > > Yes the test suite is supposed to be comleted successfully and I don't > remember a breakage for a longer time (exceptions being new patches > temporarily breaking it, but those problems have been fixed very soon by > Bram). > > If you encounter a failing test, please show the log of it. Is that really true? I always build Vim in parallel with "make -j8" but I never run tests in parallel. It would certainly be nice if tests could be run in parallel, but at the moment it does not seem safe. Here for example I see 2 tests writing the same file name "Xtest1" which prevents running tests safely in parallel. I'm almost sure that there are other cases like this: $ cd vim/src $ grep "writefile(.*'Xtest1'" *.vim test_swap.vim: call writefile(content, 'Xtest1') test_winbuf_close.vim: call writefile(['testtext 1'], 'Xtest1') 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: idle question about testing
On Di, 23 Apr 2019, tooth pik wrote: > is "make test" supposed to work currently? i can't remember the last > time i didn't > get a failed somethingorother from it > > this time it's errors in Test_incsearch_substitute_dump() > > i don't run make test very often so I'm curious -- are tests supposed > to succeed? Yes the test suite is supposed to be comleted successfully and I don't remember a breakage for a longer time (exceptions being new patches temporarily breaking it, but those problems have been fixed very soon by Bram). If you encounter a failing test, please show the log of it. Best, Christian -- Arbeit: die ewige Last, ohne die alle übrigen Lasten unerträglich würden. -- Klaus Mann -- -- 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.
