Patch 8.0.1674

[Bram Moolenaar]

Patch 8.0.1674
Problem:Libvterm can't handle a long OSC string that is split.
Solution:   When an incomplete OSC string is received copy it to the parser
buffer. Increase the size of the parser buffer to be able to
handle longer strings.
Files:  src/libvterm/src/parser.c, src/libvterm/src/vterm.c


*** ../vim-8.0.1673/src/libvterm/src/parser.c   2018-03-25 16:20:18.517264034 
+0200
--- src/libvterm/src/parser.c   2018-04-07 21:34:30.894149666 +0200
***
*** 288,293 
--- 288,298 
  done_string(vt, string_start, bytes + pos - string_start);
  ENTER_NORMAL_STATE();
}
+   else if (pos + 1 == len) {
+   /* end of input but OSC string isn't finished yet, copy it to
+* vt->parser.strbuffer to continue it later */
+ more_string(vt, string_start, bytes + pos + 1 - string_start);
+   }
break;
  
  case NORMAL:
*** ../vim-8.0.1673/src/libvterm/src/vterm.c2018-03-25 16:20:18.517264034 
+0200
--- src/libvterm/src/vterm.c2018-04-07 21:31:15.587533128 +0200
***
*** 52,58 
vt->parser.callbacks = NULL;
vt->parser.cbdata= NULL;
  
!   vt->parser.strbuffer_len = 64;
vt->parser.strbuffer_cur = 0;
vt->parser.strbuffer = vterm_allocator_malloc(vt, vt->parser.strbuffer_len);
  
--- 52,58 
vt->parser.callbacks = NULL;
vt->parser.cbdata= NULL;
  
!   vt->parser.strbuffer_len = 500; /* should be able to hold an OSC string */
vt->parser.strbuffer_cur = 0;
vt->parser.strbuffer = vterm_allocator_malloc(vt, vt->parser.strbuffer_len);
  
*** ../vim-8.0.1673/src/version.c   2018-04-07 19:27:11.938983767 +0200
--- src/version.c   2018-04-07 21:35:18.437734917 +0200
***
*** 764,765 
--- 764,767 
  {   /* Add new patch number below this line */
+ /**/
+ 1674,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
125. You begin to wonder how often it REALLY is necessary to get up
 and shower or bathe.

 /// 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: [vim/vim] errorformat %r seems to imply %> (#2785)

[Yegappan Lakshmanan]

Hi,

On Sat, Apr 7, 2018 at 7:34 AM, Yegappan Lakshmanan  wrote:
> Hi,
>
> On Fri, Apr 6, 2018 at 10:13 PM, Jan Gosmann  
> wrote:
>> I can definitely do that, but might take me a few days.
>>
>> Also, I already took a look at the code myself and was considering moving
>> the restofline label to line 847. I suppose which of these is the proper fix
>> depends on whether it makes sense to use %> with the O/P/Q patterns. There
>> is also a line fields->valid = TRUE; that would then be executed. Not
>> entirely sure what the effect of that would be.
>>
>
> Your suggestion will also work. Some user may try to use %> with the
> O/P/Q patterns. So it is better to move the restofline label. The valid field
> is used to track whether the matched quickfix entry is a valid one (with a
> filename and line number) or not. As we are starting over to find a new match,
> it makes sense to set the field to TRUE again.
>

I am attaching a patch for this issue with a test for this case.

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


multifile.diff
Description: Binary data

Re: Test failure on linux-powerpc v8.0.1670

[Bram Moolenaar]

Elimar Riesebieter wrote:

> > From test_terminal.vim:
> > Found errors in Test_terminal_api_drop_newwin_fileformat():
> > Caught exception in Test_terminal_api_drop_newwin_fileformat(): WaitFor() 
> > timed out after 2000 msec @ function 
> > RunTheTest[38]..Test_terminal_api_drop_newwin_fileformat[4]..Api_drop_common[12]..WaitFor,
> >  line 25
> 
> Increase call wait for to 5000 in test_terminal.vim seems to fix it so far:

Hmm, OK.  That's a very long time though, there must be something that
causes the long delay.  If you try something like by hand, do you notice
a delay?

-- 
Would you care for a drink?   I mean, if it were, like,
disabled and you had to look after it?

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

[Bram Moolenaar]

Patch 8.0.1673
Problem:Terminal window tests are still a bit flaky.
Solution:   Increase the waiting time even more. (Elimar Riesebieter)
Files:  src/testdir/test_terminal.vim


*** ../vim-8.0.1672/src/testdir/test_terminal.vim   2018-04-07 
10:42:09.721521211 +0200
--- src/testdir/test_terminal.vim   2018-04-07 19:22:53.321194434 +0200
***
*** 1061,1067 
\ "set t_ts=",
\ ], 'Xscript')
let buf = RunVimInTerminal('-S Xscript', {})
!   call WaitFor({-> bufnr('Xtextfile') > 0}, 2000)
call assert_equal('Xtextfile', expand('%:t'))
call assert_true(winnr('$') >= 3)
return buf
--- 1061,1067 
\ "set t_ts=",
\ ], 'Xscript')
let buf = RunVimInTerminal('-S Xscript', {})
!   call WaitFor({-> bufnr('Xtextfile') > 0}, 5000)
call assert_equal('Xtextfile', expand('%:t'))
call assert_true(winnr('$') >= 3)
return buf
*** ../vim-8.0.1672/src/version.c   2018-04-07 19:09:05.795413412 +0200
--- src/version.c   2018-04-07 19:24:03.536561956 +0200
***
*** 764,765 
--- 764,767 
  {   /* Add new patch number below this line */
+ /**/
+ 1673,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
124. You begin conversations with, "Who is your internet service provider?"

 /// 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: Test failure on linux-powerpc v8.0.1670

[Bram Moolenaar]

Elimar Riesebieter wrote:

> From test_terminal.vim:
> Found errors in Test_terminal_api_drop_newwin_fileformat():
> Caught exception in Test_terminal_api_drop_newwin_fileformat(): WaitFor() 
> timed out after 2000 msec @ function 
> RunTheTest[38]..Test_terminal_api_drop_newwin_fileformat[4]..Api_drop_common[12]..WaitFor,
>  line 25
> 
> 
> Builds on amd64 and i386 ran fine.

I haven't been able to reproduce this failure and similar ones with
"api_drop".  It also fails on Travis sometimes. I am looking forward to
get a hint on how to reproduce this failure.

Note that the similar _ff and _enc tests pass, but the _fileformat and
_encoding tests, which do exactly the same thing, then fail.  Maybe the
previous test wasn't completely finished somehow?

-- 
hundred-and-one symptoms of being an internet addict:
121. You ask for e-mail adresses instead of telephone numbers.

 /// 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: Strange ':file' command behaviour after "E23: no alternate file.

[Bram Moolenaar]

Tom M wrote:

> On Tue, Apr 3, 2018 at 7:14 PM, Bram Moolenaar  wrote:
> >
> > Tom M wrote:
> >
> >> > On Thu, Mar 29, 2018 at 2:06 PM, Bram Moolenaar 
> >> > wrote:
> >> >
> >> >>
> >> >> Tom M wrote:
> >> >>
> >> >> > First of all, thank you for VIM. Now, I'd like to share an example of
> >> >> > a rather confusing behaviour. It's the ':file' ex command when used in
> >> >> > combination with the # register. Here is how to reproduce:
> >> >> >
> >> >> > vim -N -u NONE -U NONE --noplugin somefile.txt
> >> >> >
> >> >> > :file
> >> >> > =>
> >> >> > "somefile.txt"
> >> >> >
> >> >> > :file #
> >> >> > =>
> >> >> > :file "
> >> >> > E23: No alternate file
> >> >> > :file |
> >> >> > (vim still in ex cmd input mode with the cursor positioned where '|' 
> >> >> > is)
> >> >> >
> >> >> > otherfile.txt
> >> >> > (this finishes the input of ':file otherfile.txt' ex command.)
> >> >> >
> >> >> > :file
> >> >> > =>
> >> >> > "somefile.txt"
> >> >> >
> >> >> > IOW the resulting 'file otherfile.txt' command failed without warning.
> >> >> Is this a bug or a "feature"? Because this definitely doesn't feel 
> >> >> right. I
> >> >> would expect one of these results (in my order of preference):
> >> >> >
> >> >> > 1) The 'file otherfile.txt' ex cmd goes through so that ':file' gives
> >> >> 'otherfile.txt' in the end.
> >> >> > 2) Immediate abort after E23.
> >> >> > 3) Or at least some notification that the file was not changed to
> >> >> 'b.txt'.
> >> >> >
> >> >> > This is VIM 8.0.1648 on a Linux machine. VIM 7.4 is affected too.
> >> >>
> >> >> I can reproduce it.  So the suspicion is that the error for the missing
> >> >> register causes the command to fail later.
> >> >>
> >> >>
> >> > It's my very first look into the source code. I'm not able to come up
> >> > with a patch alone. Anyway, in 8.0.1648 I am seeing this:
> >> >
> >> > buffer.c3230getaltfname() EMSG(_(e_noalt));
> >> > ex_docmd.c  2000do_one_cmd() ea.skip = did_emsg || got_int || ...
> >> >
> >> > So when "E23: No alternate file" is displayed, did_emsg is set to TRUE.
> >> > Then later in do_one_cmd() ea.skip is set to TRUE because of
> >> > did_emsg==TRUE.  ea.skip variable is described as "don't execute the
> >> > command, only parse it".  Indeed, further code of the function parses the
> >> > ex command but stops right before executing it when it sees that ea.skip 
> >> > is
> >> > TRUE. Obviously, preventing the ea.skip variable to become TRUE would get
> >> > the ex command executed and fix the issue for me. But surely the ea.skip
> >> > thing was put there for a reason. I cannot exactly guess the exact reason
> >> > just now.
> >> >
> >> > Maybe it's something like "an error occured, proceed to next ex command".
> >> > But why not abandon the execution right after E23? Why let the user 
> >> > correct
> >> > his entry when we know the ex cmd is going to be skipped either way? Why
> >> > let vim's code execution reach do_one_cmd() when the E23 is displayed 
> >> > quite
> >> > a few fn calls sooner?
> >> >
> >> > Eperiments show that the problem is "generic" somewhat. E.g. ":echo
> >> > #" is affected in the same way. So it's not the ":file" ex cmd
> >> > only. So maybe, when issuing an error message, vim should somehow
> >> > distinguish between fatal errors (then set did_emsg=true) and non-fatal
> >> > errors (like E23 in this case) and perhaps only do something like
> >> > did_warn=true.
> >> >
> >> > BTW, as mentioned earlier, another kind of fix that would work for me is
> >> > to just alert the user when the ":file" ex command is aborted.
> >> >
> >> > So, can someone shed some light for me on (1) the ea.skip thing or (2) 
> >> > how
> >> > to do the alerting or (3) how to prevent forther's user input after the 
> >> > E23
> >> > or (4) how to distinguish between "fatal" and "non-fatal" errors, please?
> >> > Or, even better, come up right with a proper patch? :-)
> >> >
> >> > Thanks,
> >> >
> >> > Tom
> >> >
> >> >
> >> Experiments inspired by the code of get_spec_reg() show that what's
> >> affected is input of any ex command that involves  followed by '#',
> >> '%', '=1+' (any invalid expression), '', '.' or ':' in
> >> corresponding specific situations.
> >> Examples:
> >>
> >> :file %i_2.txt " with no current file
> >> :echo "alt file is: #" " with no alternate file
> >> :let x= >> :sp other.txt " on empty line
> >> :echo "last cmd: :" " as first ex command
> >>
> >> Here is a patch I managed to come up with. It solves the issue for me. The
> >> ex commands after E23 (and friends) go through. I'll be happy to hear your
> >> oppinion. (But it's my first, so go easy on me ;-)
> >
> > Thanks.   I don't think it is needed to save the previous value of
> > did_emsg.  It is reset at the start of getcmdline() anyway.  I'm even
> > tempted to reset it in the loop, before getting the next character.
> > There can't really be a reason 

Patch 8.0.1672

[Bram Moolenaar]

Patch 8.0.1672
Problem:Error during completion causes command to be cancelled.
Solution:   Reset did_emsg before waiting for another character. (Tom M.)
Files:  src/ex_getln.c, src/testdir/test_cmdline.vim


*** ../vim-8.0.1671/src/ex_getln.c  2018-03-29 15:55:30.870510215 +0200
--- src/ex_getln.c  2018-04-07 19:00:20.534336924 +0200
***
*** 426,431 
--- 426,435 
  #endif
quit_more = FALSE;  /* reset after CTRL-D which had a more-prompt */
  
+   did_emsg = FALSE;   /* There can't really be a reason why an error
+  that occurs while typing a command should
+  cause the command not to be executed. */
+ 
cursorcmd();/* set the cursor on the right spot */
  
/* Get a character.  Ignore K_IGNORE and K_NOP, they should not do
*** ../vim-8.0.1671/src/testdir/test_cmdline.vim2018-03-29 
15:55:30.874510195 +0200
--- src/testdir/test_cmdline.vim2018-04-07 18:59:42.646552205 +0200
***
*** 316,321 
--- 316,332 
call feedkeys(":\etoupper(getline(1))\\\"\", 'tx')
call assert_equal('"ASDF.X /TMP/SOME VERYLONGWORD A;B-C*D ', @:)
bwipe!
+ 
+   " Error while typing a command used to cause that it was not executed
+   " in the end.
+   new
+   try
+ call feedkeys(":file \%Xtestfile\", 'tx')
+   catch /^Vim\%((\a\+)\)\=:E32/
+ " ignore error E32
+   endtry
+   call assert_equal("Xtestfile", bufname("%"))
+   bwipe!
  endfunc
  
  func Test_remove_char_in_cmdline()
*** ../vim-8.0.1671/src/version.c   2018-04-07 13:22:15.566979906 +0200
--- src/version.c   2018-04-07 19:03:43.053198295 +0200
***
*** 764,765 
--- 764,767 
  {   /* Add new patch number below this line */
+ /**/
+ 1672,
  /**/

-- 
~
~
~
".signature" 4 lines, 50 characters written

 /// 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: Test failure on linux-powerpc v8.0.1670

[Elimar Riesebieter]

* Elimar Riesebieter  [2018-04-07 13:20 +0200]:

> >From test_terminal.vim:
> Found errors in Test_terminal_api_drop_newwin_fileformat():
> Caught exception in Test_terminal_api_drop_newwin_fileformat(): WaitFor() 
> timed out after 2000 msec @ function 
> RunTheTest[38]..Test_terminal_api_drop_newwin_fileformat[4]..Api_drop_common[12]..WaitFor,
>  line 25

Increase call wait for to 5000 in test_terminal.vim seems to fix it so far:

>From 27c1ef8d2c47d33f9723f4f619c1be6783af91d4 Mon Sep 17 00:00:00 2001
From: Elimar Riesebieter 
Date: Sat, 7 Apr 2018 16:19:00 +0200
Subject: [PATCH] Increase call wait for to 5000 in test_terminal.vim

---
 src/testdir/test_terminal.vim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/testdir/test_terminal.vim b/src/testdir/test_terminal.vim
index cd7a2b21e..5645625cb 100644
--- a/src/testdir/test_terminal.vim
+++ b/src/testdir/test_terminal.vim
@@ -1061,7 +1061,7 @@ func Api_drop_common(options)
\ "set t_ts=",
\ ], 'Xscript')
   let buf = RunVimInTerminal('-S Xscript', {})
-  call WaitFor({-> bufnr('Xtextfile') > 0}, 2000)
+  call WaitFor({-> bufnr('Xtextfile') > 0}, 5000)
   call assert_equal('Xtextfile', expand('%:t'))
   call assert_true(winnr('$') >= 3)
   return buf
-- 
2.17.0


-- 
  Numeric stability is probably not all that
  important when you're guessing;-)

-- 
-- 
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] errorformat %r seems to imply %> (#2785)

[Yegappan Lakshmanan]

Hi,

On Fri, Apr 6, 2018 at 10:13 PM, Jan Gosmann  wrote:
> I can definitely do that, but might take me a few days.
>
> Also, I already took a look at the code myself and was considering moving
> the restofline label to line 847. I suppose which of these is the proper fix
> depends on whether it makes sense to use %> with the O/P/Q patterns. There
> is also a line fields->valid = TRUE; that would then be executed. Not
> entirely sure what the effect of that would be.
>

Your suggestion will also work. Some user may try to use %> with the
O/P/Q patterns. So it is better to move the restofline label. The valid field
is used to track whether the matched quickfix entry is a valid one (with a
filename and line number) or not. As we are starting over to find a new match,
it makes sense to set the field to TRUE again.

- Yegappan

>
> I'm not familiar with the
> Vim code base and even learned about the errorformat just in the last couple
> of days, but maybe it is helpful to have these things mentioned.
>

-- 
-- 
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: Strange ':file' command behaviour after "E23: no alternate file.

[Tom M]

On Tue, Apr 3, 2018 at 7:14 PM, Bram Moolenaar  wrote:
>
> Tom M wrote:
>
>> > On Thu, Mar 29, 2018 at 2:06 PM, Bram Moolenaar 
>> > wrote:
>> >
>> >>
>> >> Tom M wrote:
>> >>
>> >> > First of all, thank you for VIM. Now, I'd like to share an example of
>> >> > a rather confusing behaviour. It's the ':file' ex command when used in
>> >> > combination with the # register. Here is how to reproduce:
>> >> >
>> >> > vim -N -u NONE -U NONE --noplugin somefile.txt
>> >> >
>> >> > :file
>> >> > =>
>> >> > "somefile.txt"
>> >> >
>> >> > :file #
>> >> > =>
>> >> > :file "
>> >> > E23: No alternate file
>> >> > :file |
>> >> > (vim still in ex cmd input mode with the cursor positioned where '|' is)
>> >> >
>> >> > otherfile.txt
>> >> > (this finishes the input of ':file otherfile.txt' ex command.)
>> >> >
>> >> > :file
>> >> > =>
>> >> > "somefile.txt"
>> >> >
>> >> > IOW the resulting 'file otherfile.txt' command failed without warning.
>> >> Is this a bug or a "feature"? Because this definitely doesn't feel right. 
>> >> I
>> >> would expect one of these results (in my order of preference):
>> >> >
>> >> > 1) The 'file otherfile.txt' ex cmd goes through so that ':file' gives
>> >> 'otherfile.txt' in the end.
>> >> > 2) Immediate abort after E23.
>> >> > 3) Or at least some notification that the file was not changed to
>> >> 'b.txt'.
>> >> >
>> >> > This is VIM 8.0.1648 on a Linux machine. VIM 7.4 is affected too.
>> >>
>> >> I can reproduce it.  So the suspicion is that the error for the missing
>> >> register causes the command to fail later.
>> >>
>> >>
>> > It's my very first look into the source code. I'm not able to come up
>> > with a patch alone. Anyway, in 8.0.1648 I am seeing this:
>> >
>> > buffer.c3230getaltfname() EMSG(_(e_noalt));
>> > ex_docmd.c  2000do_one_cmd() ea.skip = did_emsg || got_int || ...
>> >
>> > So when "E23: No alternate file" is displayed, did_emsg is set to TRUE.
>> > Then later in do_one_cmd() ea.skip is set to TRUE because of
>> > did_emsg==TRUE.  ea.skip variable is described as "don't execute the
>> > command, only parse it".  Indeed, further code of the function parses the
>> > ex command but stops right before executing it when it sees that ea.skip is
>> > TRUE. Obviously, preventing the ea.skip variable to become TRUE would get
>> > the ex command executed and fix the issue for me. But surely the ea.skip
>> > thing was put there for a reason. I cannot exactly guess the exact reason
>> > just now.
>> >
>> > Maybe it's something like "an error occured, proceed to next ex command".
>> > But why not abandon the execution right after E23? Why let the user correct
>> > his entry when we know the ex cmd is going to be skipped either way? Why
>> > let vim's code execution reach do_one_cmd() when the E23 is displayed quite
>> > a few fn calls sooner?
>> >
>> > Eperiments show that the problem is "generic" somewhat. E.g. ":echo
>> > #" is affected in the same way. So it's not the ":file" ex cmd
>> > only. So maybe, when issuing an error message, vim should somehow
>> > distinguish between fatal errors (then set did_emsg=true) and non-fatal
>> > errors (like E23 in this case) and perhaps only do something like
>> > did_warn=true.
>> >
>> > BTW, as mentioned earlier, another kind of fix that would work for me is
>> > to just alert the user when the ":file" ex command is aborted.
>> >
>> > So, can someone shed some light for me on (1) the ea.skip thing or (2) how
>> > to do the alerting or (3) how to prevent forther's user input after the E23
>> > or (4) how to distinguish between "fatal" and "non-fatal" errors, please?
>> > Or, even better, come up right with a proper patch? :-)
>> >
>> > Thanks,
>> >
>> > Tom
>> >
>> >
>> Experiments inspired by the code of get_spec_reg() show that what's
>> affected is input of any ex command that involves  followed by '#',
>> '%', '=1+' (any invalid expression), '', '.' or ':' in
>> corresponding specific situations.
>> Examples:
>>
>> :file %i_2.txt " with no current file
>> :echo "alt file is: #" " with no alternate file
>> :let x=> :sp other.txt " on empty line
>> :echo "last cmd: :" " as first ex command
>>
>> Here is a patch I managed to come up with. It solves the issue for me. The
>> ex commands after E23 (and friends) go through. I'll be happy to hear your
>> oppinion. (But it's my first, so go easy on me ;-)
>
> Thanks.   I don't think it is needed to save the previous value of
> did_emsg.  It is reset at the start of getcmdline() anyway.  I'm even
> tempted to reset it in the loop, before getting the next character.
> There can't really be a reason why an error that occurs while typing a
> command should cause the command not to be executed.  Unless perhaps the
> command wasn't typed, but resulting from a script.  But making a
> difference between something that was typed or not makes life more
> difficult.  So lets not use this check up 

Patch 8.0.1671

[Bram Moolenaar]

Patch 8.0.1671
Problem:Crash when passing non-dict argument as env to job_start().
Solution:   Check for valid argument. (Ozaki Kiichi, closes #2765)
Files:  src/channel.c, src/testdir/test_channel.vim


*** ../vim-8.0.1670/src/channel.c   2018-04-03 12:50:55.509298311 +0200
--- src/channel.c   2018-04-07 13:16:03.576867619 +0200
***
*** 4797,4805 
{
if (!(supported2 & JO2_ENV))
break;
opt->jo_set2 |= JO2_ENV;
opt->jo_env = item->vval.v_dict;
!   ++item->vval.v_dict->dv_refcount;
}
else if (STRCMP(hi->hi_key, "cwd") == 0)
{
--- 4797,4811 
{
if (!(supported2 & JO2_ENV))
break;
+   if (item->v_type != VAR_DICT)
+   {
+   EMSG2(_(e_invargval), "env");
+   return FAIL;
+   }
opt->jo_set2 |= JO2_ENV;
opt->jo_env = item->vval.v_dict;
!   if (opt->jo_env != NULL)
!   ++opt->jo_env->dv_refcount;
}
else if (STRCMP(hi->hi_key, "cwd") == 0)
{
*** ../vim-8.0.1670/src/testdir/test_channel.vim2018-04-05 
22:44:33.775423796 +0200
--- src/testdir/test_channel.vim2018-04-07 13:16:03.576867619 +0200
***
*** 1720,1729 
  
let g:envstr = ''
if has('win32')
! call job_start(['cmd', '/c', 'echo %FOO%'], {'callback': 
{ch,msg->execute(":let g:envstr .= msg")}, 'env':{'FOO': 'bar'}})
else
! call job_start([, , 'echo $FOO'], {'callback': 
{ch,msg->execute(":let g:envstr .= msg")}, 'env':{'FOO': 'bar'}})
endif
call WaitFor('"" != g:envstr')
call assert_equal("bar", g:envstr)
unlet g:envstr
--- 1720,1731 
  
let g:envstr = ''
if has('win32')
! let cmd = ['cmd', '/c', 'echo %FOO%']
else
! let cmd = [, , 'echo $FOO']
endif
+   call assert_fails('call job_start(cmd, {"env": 1})', 'E475:')
+   call job_start(cmd, {'callback': {ch,msg -> execute(":let g:envstr .= 
msg")}, 'env': {'FOO': 'bar'}})
call WaitFor('"" != g:envstr')
call assert_equal("bar", g:envstr)
unlet g:envstr
***
*** 1737,1747 
let g:envstr = ''
if has('win32')
  let expect = $TEMP
! let job = job_start(['cmd', '/c', 'echo %CD%'], {'callback': 
{ch,msg->execute(":let g:envstr .= msg")}, 'cwd': expect})
else
  let expect = $HOME
! let job = job_start(['pwd'], {'callback': {ch,msg->execute(":let g:envstr 
.= msg")}, 'cwd': expect})
endif
try
  call WaitFor('"" != g:envstr')
  let expect = substitute(expect, '[/\\]$', '', '')
--- 1739,1750 
let g:envstr = ''
if has('win32')
  let expect = $TEMP
! let cmd = ['cmd', '/c', 'echo %CD%']
else
  let expect = $HOME
! let cmd = ['pwd']
endif
+   let job = job_start(cmd, {'callback': {ch,msg -> execute(":let g:envstr .= 
msg")}, 'cwd': expect})
try
  call WaitFor('"" != g:envstr')
  let expect = substitute(expect, '[/\\]$', '', '')
*** ../vim-8.0.1670/src/version.c   2018-04-07 10:42:09.725521193 +0200
--- src/version.c   2018-04-07 13:19:27.207814603 +0200
***
*** 764,765 
--- 764,767 
  {   /* Add new patch number below this line */
+ /**/
+ 1671,
  /**/

-- 
An actual excerpt from a classified section of a city newspaper:
"Illiterate?  Write today for free help!"

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

Test failure on linux-powerpc v8.0.1670

[Elimar Riesebieter]

>From test_terminal.vim:
Found errors in Test_terminal_api_drop_newwin_fileformat():
Caught exception in Test_terminal_api_drop_newwin_fileformat(): WaitFor() timed 
out after 2000 msec @ function 
RunTheTest[38]..Test_terminal_api_drop_newwin_fileformat[4]..Api_drop_common[12]..WaitFor,
 line 25


Builds on amd64 and i386 ran fine.

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.

Patch 8.0.1670

[Bram Moolenaar]

Patch 8.0.1670
Problem:Terminal window tests are still a bit flaky.
Solution:   Increase the waiting time for the buffer to be created.
Files:  src/testdir/test_terminal.vim


*** ../vim-8.0.1669/src/testdir/test_terminal.vim   2018-04-04 
22:57:24.113853625 +0200
--- src/testdir/test_terminal.vim   2018-04-07 10:40:32.133964336 +0200
***
*** 1061,1067 
\ "set t_ts=",
\ ], 'Xscript')
let buf = RunVimInTerminal('-S Xscript', {})
!   call WaitFor({-> bufnr('Xtextfile') > 0})
call assert_equal('Xtextfile', expand('%:t'))
call assert_true(winnr('$') >= 3)
return buf
--- 1061,1067 
\ "set t_ts=",
\ ], 'Xscript')
let buf = RunVimInTerminal('-S Xscript', {})
!   call WaitFor({-> bufnr('Xtextfile') > 0}, 2000)
call assert_equal('Xtextfile', expand('%:t'))
call assert_true(winnr('$') >= 3)
return buf
*** ../vim-8.0.1669/src/version.c   2018-04-06 22:58:18.762068116 +0200
--- src/version.c   2018-04-07 10:41:42.117647428 +0200
***
*** 764,765 
--- 764,767 
  {   /* Add new patch number below this line */
+ /**/
+ 1670,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
118. You are on a first-name basis with your ISP's staff.

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