On Thu, Mar 29, 2018 at 2:06 PM, Bram Moolenaar <[email protected]> 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




> --
> hundred-and-one symptoms of being an internet addict:
> 86. E-mail Deficiency Depression (EDD) forces you to e-mail yourself.
>
>  /// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui