On 31/01/10 18:12, Gary Johnson wrote:
On 2010-01-30, Bee wrote:
On Jan 29, 10:52 am, "Benjamin R. Haskell"<v...@benizi.com> wrote:
On Fri, 29 Jan 2010, Bee wrote:
On Jan 29, 7:43 am, "Benjamin R. Haskell"<v...@benizi.com> wrote:
...
:redir @a
...
How to save directly to a filename?
[...]
But this creates a file named savevimrc in $HOME
redir> savevimrc
How to expand savevimrc to the file name?
:exe "redir> " . savevimrc
Will this always do the same?
:exe "redir>" savevimrc
Yes.
From what I have read '.' concatenates without adding spaces,
whereas without using '.' a space will be added.
'.' is an expression operator and will concatenate two strings in a
context where an expression is allowed. Not having to use a '.'
between arguments of an exe command is a property of the exe
command, which concatenates all of its arguments with intervening
spaces.
Is it just better to get the habit of using '.' ?
No, not if you're paying attention to the context in which you're
concatenating strings. I prefer not to use the '.' in exe arguments
if I can avoid it because it looks less cluttered.
Now that I look at them, the examples under ":help :exe" are
confusing. The first two examples include spaces after the executed
command names even though none are needed there.
Regards,
Gary
I agree: both "exe[cute]" and "echo" treat their arguments the same way:
any number of expressions are allowed, and their values are concatenated
space-separated into one long string before being further processed.
Then :echo displays the result while :exe treats it as an ex-command
line. IOW you can always use :echo instead of :exe to make sure which
ex-command :exe would generate.
Me too, I prefer using
:exe "command" variable1 variable2 variable3
rather than
:exe "command " . variable1 . " " . variable2 . " " . variable3
It's easier to type, and at least as easy to understand once you
remember that :echo and :exe both accept any number of arguments, which
they will concatenate in the same manner.
And indeed, that behaviour is not going to change: it would needlessly
break compatibility with uncounted existing scripts, something which
Bram would never accept (needlessly breaking, I mean: a compatibility
break is only accepted when there is an obvious advantage and no great
risk in doing so, for instance when 1.23 was redefined as the floating
number "one unit and twenty-three hundredths" where before it had been
the string expression 1 . 23, which evaluated to '123' [and with the
spaces it still does]).
Best regards,
Tony.
--
Experience is what you get when you don't get what you want.
--
You received this message from the "vim_use" 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
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or
reply to this email with the words "REMOVE ME" as the subject.
