On Tue, Apr 3, 2018 at 7:14 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
> > Tom M wrote: > > > > On Thu, Mar 29, 2018 at 2:06 PM, Bram Moolenaar <b...@moolenaar.net> > > > 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 <CTRL-R># > > >> > => > > >> > :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.c 3230 getaltfname() EMSG(_(e_noalt)); > > > ex_docmd.c 2000 do_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 > > > <CTRL-R>#" 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 <CTRL-R> followed by > '#', > > '%', '=1+' (any invalid expression), '<CTRL-F>', '.' or ':' in > > corresponding specific situations. > > Examples: > > > > :file <CTRL-R>%i_2.txt " with no current file > > :echo "alt file is: <CTRL-R>#" " with no alternate file > > :let x=<CTRL-R)=x+ " any syntactically incorrect expression > > :sp <CTRL-R><CTRL-F>other.txt " on empty line > > :echo "last cmd: <CTRL-R>:" " 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 front. > > In the meantime I am thinking about a test. How about something along these lines? diff --git a/src/testdir/test_cmdline.vim b/src/testdir/test_cmdline.vim index 8755fbf1a..ccc1d3353 100644 --- a/src/testdir/test_cmdline.vim +++ b/src/testdir/test_cmdline.vim @@ -316,6 +316,16 @@ func Test_paste_in_cmdline() call feedkeys(":\<C-\>etoupper(getline(1))\<CR>\<C-B>\"\<CR>", 'tx') call assert_equal('"ASDF.X /TMP/SOME VERYLONGWORD A;B-C*D ', @:) bwipe! + + " Pasting special registers into command line used to abort commands + " in specific situations + new + try + call feedkeys(":file \<C-R>%Xtestfile\<CR>", 'tx') + catch /^Vim\%((\a\+)\)\=:E32/ " catch error E32 + endtry + call assert_equal("Xtestfile", bufname("%")) + bwipe! endfunc func Test_remove_char_in_cmdline() Tom > > -- > I AM THANKFUL... > ...for all the complaining I hear about the government > because it means we have freedom of speech. > > /// 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.