On Mon, Apr 2, 2018 at 1:33 AM, Tom M <[email protected]> wrote:
>
>
> 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
>
>
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 ;-)
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 48cccf18e..90528b891 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -3289,6 +3289,7 @@ cmdline_paste(
char_u *arg;
char_u *p;
int allocated;
+ int save_did_emsg;
struct cmdline_info save_ccline;
/* check for valid regname; also accept special characters for CTRL-R
in
@@ -3307,12 +3308,15 @@ cmdline_paste(
regname = may_get_selection(regname);
#endif
- /* Need to save and restore ccline. And set "textlock" to avoid nasty
- * things like going to another buffer when evaluating an expression.
*/
+ /* Need to save and restore ccline and did_emsg. And set "textlock"
+ * to avoid nasty things like going to another buffer when evaluating
+ * an expression. */
save_cmdline(&save_ccline);
+ save_did_emsg = did_emsg;
++textlock;
i = get_spec_reg(regname, &arg, &allocated, TRUE);
--textlock;
+ did_emsg = save_did_emsg;
restore_cmdline(&save_ccline);
if (i)
If I'll hear that it's not a completely wrong direction, I'll try to come
up with a test.
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.
