Hello Taro,
Excerpt from MURAOKA Taro:
-- snip --
I have updated files which I had provided.
Please check attachement and include into vim distribution.
Changes are:
* Update translations
- src/po/ja.po
- src/po/ja.sjis.po
* Add license notice (of course under VIM license)
-
Hello
-- snip --
multi-line strings should have a line ending like '\n'
in 'src/po/ja.po' there are multi-line strings e.g. line 3087 that are missing
the '\n'.
OK drop that since it is nonsense. But i wonder if '$PATH' will be replaced with
some real path. In that case it might worthwhile to
We discussed this previously. I think it's simpler to use :p to get the
full path and when someone needs the 8.3 name use :8 after that. No
need for a new modifier.
I updated patch.
https://gist.github.com/2936050
Previous were broken memory.
--
You received this message from the vim_dev
Try following.
:set wildignore+=*.bak
:e `=foo.bak`
E480: No match: `=foo.bak`
I think, this should be matched to wildignore. Also :e `ls foo.c`.
https://gist.github.com/2936402
Bram, please check.
BTW, fnameescape() have bugs that wasn't fixed yet on windows.
I think, this should be matched to wildignore. Also :e `ls foo.c`.
Sorry typo.
I think, this should NOT be matched to wildignore.
--
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
On 15-Jun-2012 06:09:54 -0700 (PDT), mattn wrote:
Try following.
:set wildignore+=*.bak
:e `=foo.bak`
E480: No match: `=foo.bak`
I think, this should be matched to wildignore. Also :e `ls foo.c`.
I have the opinion that having 'wildignore' apply (they way it is now) is more
consistent
On 15-Jun-2012 15:35:05 +0200, Ingo Karkat wrote:
The issue is that some plugin writers have used backtick expansion as
a workaround for the mentioned bugs in fnameescape().
I think the help text could also be more clear about 'wildignore'; I only found
out about this behavior by chance.
--
No. Currentry, `=foo` is a just only way that can specify argument
without escaping, and can specify non-valid filename. This is usefull
to make buffer with especially name. ex: [##My Buffer##].
If applies wildignore or suffixes for this, we must avoid to match to
them with that backup and specify
Christian Brabandt wrote:
On Do, 14 Jun 2012, Bram Moolenaar wrote:
My definition of valid is something that diff would produce. Can you
show me two input files for which diff produces an ed style diff with
adjecent blocks?
Seems, the more widely used diffs, always merge adjacent
Yasuhiro Matsumoto wrote:
Try following.
:set wildignore+=*.bak
:e `=foo.bak`
E480: No match: `=foo.bak`
I think, this should be matched to wildignore. Also :e `ls foo.c`.
https://gist.github.com/2936402
Bram, please check.
BTW, fnameescape() have bugs that wasn't fixed yet on
Taro Muraoka wrote:
I have updated files which I had provided.
Please check attachement and include into vim distribution.
Changes are:
* Update translations
- src/po/ja.po
- src/po/ja.sjis.po
* Add license notice (of course under VIM license)
- src/po/ja.po
-
On 16-Jun-2012 01:18:24 +0900, Yasuhiro MATSUMOTO wrote:
No. Currentry, `=foo` is a just only way that can specify argument
without escaping, and can specify non-valid filename. This is usefull
to make buffer with especially name. ex: [##My Buffer##].
fnameescape() will properly escape that.
This script fails with E741: Value is locked: extend() argument.
for i in range(1)
function Foo{i}()
call extend(l:, {})
endfunction
call Foo{i}()
endfor
funccall_T.l_vars.dv_lock is not initialized.
diff -r ca39f14c1ec3 src/eval.c
--- a/src/eval.cThu Jun 14 20:59:25 2012
13 matches
Mail list logo
