> Isn't this to do with the fact that "<(...)" causes the shell to create
> a temporary file
It does not. It is =(...) that uses temporary files (assuming you use zsh),
<(...) creates file descriptors before forking and attaches them to ...’s
stdout.
> which is then sourced by ViM, and in ViM, all block constructs must be
> terminated
> by the end of the current file, therwise an error occurs.
Error?! Where have you seen a word about *occurring* error?
Originally I checked this on a running vim by *typing* :bufdo if 1.
>
> "-c" on the other hand simply executes an Ex command as if it had been
> entered
> interactively by the user. There is no file scope
`-s` is not regular sourcing. There is a thing which you may call “file scope”:
implementation-defined differences in Ex commands handling (e.g. line
continuation working only in files), but this has nothing to do with -s: it
feeds input like if it was typed.
> therefore there is no
> error output if
> the end of the block is missing.
:h :execute, third-last paragraph:
> Note: The executed string may be any command-line, but
> you cannot start or end a "while", "for" or "if"
> command. Thus this is illegal: >
> :execute 'while i > 5'
> :execute 'echo "test" | break'
. Even though with :execute it works it is explicitly marked as illegal. Will
you say :execute has file scope?
// Note about “works”:
execute 'if '.condition
works like
if eval(condition)
, be it in file or not: i.e. it expects endif in the following lines.
>
> To me it looks like ViM is working normally here.
--
--
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.
