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.
