Hi Pavol
On 2015-07-21 Tuesday at 18:33 -0400 Pavol Juhas wrote:
> On Monday, July 20, 2015 at 5:38:10 PM UTC-4, Roland Eggner wrote:
> ...
> > I reproduced with vim-7.4.529:
> >
> > :e `=$HOME . '/.vimrc'`
> > E15: Invalid expression: /home/roland . '/.vimrc'
> > "`=/home/roland . '/.vimrc'`" [New DIRECTORY]
> > :e `=expand('$HOME') . '/vimrc'`
> > :ls
> > 1 # "`=/home/roland . '/.vimrc'`" line 1
> > 3 %a "~/.vimrc" line 1
>
> Hi Roland,
>
> The variant with expand() works, because it happens to quote the
> value of $HOME, in other words
>
> :e `= expand('$HOME') . '/.vimrc' `
>
> replaces the back-ticked string with the result of VimL expression
>
> expand('/home/roland') . './vimrc'
>
> It actually also works without the expand() call:
>
> :e `= '$HOME' . '/.vimrc' `
> [ backticks replaced with --> '/home/roland' . '/.vimrc' ]
Interesting. And another surprise: this works even without the
concatenation, see example 2 below.
> I'd however expect this to open a .vimrc file in a literal
> <Dollar>HOME directory.
I had the same expectation, thus did not try it until now.
Here is my summary of working and not working variants of quoted or unquoted
environment variables inside `= … ` expressions, each represented by an
example:
LC_ALL=C HOME_quoted="\"$HOME\"" vim -u NONE -i NONE -N
:e `='$HOME' . '/.zshrc1'`
:e `='$HOME/.zshrc2'`
:e `="$HOME" . '/.zshrc3'`
:e `="$HOME/.zshrc4"`
:e `=expand('$HOME') . '/.zshrc5'`
:e `=$HOME_quoted . '/.zshrc6'`
:e `=$HOME . '/.zshrc7'`
E15: Invalid expression: /home/roland . '/.zshrc7'
"`=/home/roland . '/.zshrc7'`" [New DIRECTORY]
:e `='"' . $HOME . '"/.zshrc8'`
E15: Invalid expression: /home/roland . '"/.zshrc8'
"`='"' . /home/roland . '"/.zshrc8'`" [New DIRECTORY]
:e `="'" . $HOME . "'" . '/.zshrc9'`
E15: Invalid expression: /home/roland . "'" . '/.zshrc9'
"`="'" . /home/roland . "'" . '/.zshrc9'`" [New DIRECTORY]
:ls
1 "~/.zshrc1" line 1
2 "~/.zshrc2" line 1
3 "~/.zshrc3" line 1
4 "~/.zshrc4" line 1
5 "~/.zshrc5" line 1
6 "~/.zshrc6" line 1
7 "`=/home/roland . '/.zshrc7'`" line 1
8 # "`='"' . /home/roland . '"/.zshrc8'`" line 1
9 %a "`="'" . /home/roland . "'" . '/.zshrc9'`" line 1
Probably we can agree: there is some inconsistency.
> > The usual solution for this type of error is insertion of a call to
> > expand(),
> > this works for me in this case too, thus I would not consider the issue as
> > bug.
>
> >From my point of view this is a bug, because per Vim documentation
> `={expr}` should accept VimL expressions, and
>
> $HOME . '/.vimrc'
>
> is a perfectly legitimate expression. The fact that the expand()
> works is not relevant and in actuality is just a coincidence.
> The expand() function does not do anything, it is the quoting of
> the prematurely-expanded $HOME that matters.
Agreed. Your and mine investigations seem to lead to the same result:
at its core it is a quoting issue.
> ...
> > > :let f = 'filename with special characters *#'
> > > :execute 'edit' fnameescape(f)
> > > :edit `=f`
> >
> > For me the former has the advantages
> > • well documented
> > • works at any place, where strings are expected in ex-commands
> > • I use it frequently every day in vim scripts (rather rarely at the vim
> > commandline, because I load files mostly by loading session files, by a
> > vim
> > command of the “gf” family, or by calling vim from another utility like
> > mutt,
> > git, hg, mc, zsh, …)
> >
> > whereas the latter
> > • works only at places, where filenames are expected as arguments to
> > ex-commands
> > • to me the syntax looks obscure and against intuition
>
>
> It is a matter of taste. If Vim has the `= feature, it would
> be nice to have it handle the environment variables as all the
> other VimL expressions do.
Agreed, consistency is almost always appreciated. E.g. with its consistent
implementation of movement commands and their combination with operators vim
shines brightest.
Bram's primary goals seems to be
(1) keep backwards compatibility
(2) try to make everybody happy
This leads to two consequences:
• upside: much flexibility
• downside: some compromises regarding consistency are unavoidable
We have the freedom to choose:
(a) Enjoy flexibility and tolerate some inconsistency.
(b) Choose preferred variants, forget alternatives, and enjoy consistency.
--
Best regards,
Roland Eggner
--
--
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.
pgpnlDoO4BqLJ.pgp
Description: PGP signature
