Tom M wrote:

> 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.
> 
> I am attaching a new version of patch. It's changed according your
> suggestion. The did_emsg flag is reset at the beginning of the loop
> before getting the next caracter. The patch contains a test too. The
> test is the same as before. Please check it out.

Thanks. Let's include this now, and see if this causes any problem.
I won't expect a problem though.

-- 
"Computers in the future may weigh no more than 1.5 tons."
                                   Popular Mechanics, 1949

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

Raspunde prin e-mail lui