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