On 20 August 2013, David Barnett daviebd...@gmail.com wrote:
Ensure ./foo doesn't exist, and do
:call mkdir('foo/bar/', 'p')
Vim gives you an error:
E739: Cannot create directory: foo/bar/
but the directory was created just fine.
Dropping the trailing slash works without error:
On Wed, Aug 21, 2013 at 01:56:31PM +0300, LCD 47 wrote:
On 20 August 2013, David Barnett daviebd...@gmail.com wrote:
Ensure ./foo doesn't exist, and do
:call mkdir('foo/bar/', 'p')
Vim gives you an error:
E739: Cannot create directory: foo/bar/
but the directory was created just
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 161 by stefan.l...@gmail.com: Can't see the output of :make
while it's running in MS Windows
http://code.google.com/p/vim/issues/detail?id=161
What steps will reproduce the problem?
1. :set shellpipe 21\ |\ tee.exe
2.
On 21 August 2013, Marius Gedminas mar...@gedmin.as wrote:
On Wed, Aug 21, 2013 at 01:56:31PM +0300, LCD 47 wrote:
On 20 August 2013, David Barnett daviebd...@gmail.com wrote:
Ensure ./foo doesn't exist, and do
:call mkdir('foo/bar/', 'p')
Vim gives you an error:
E739:
Hi,
Tested with the latest version of Vim from Mercurial.
After a * search, then cgn and then . to repeat it for all matches,
I cannot continue past the end of file and change any matches before my initial
position
Regards
Dimitar
---
GPG Key: 2048R/160C6FA8 2012-10-11 Dimitar Dimitrov
Comment #1 on issue 161 by stefan.l...@gmail.com: Can't see the output
of :make while it's running in MS Windows
http://code.google.com/p/vim/issues/detail?id=161
Additional info: ':!dir' does open a console window (in the foreground)
--
You received this message because this project is
Manuel Ortega wrote:
As noted in an earlier thread, I discovered that most attributes to
:command can be abbreviated. I discovered this only by accident, looking
in syntax/vim.vim.
Turns out, in that syntax file (a) there is no support for the attribute
-buffer (for buflocal commands),
LCD 47 wrote:
..snip..
+1 for this. People routinely edit files that only make sense (and
will only ever run) on remote servers. There are legitimate situations
where editing a file has nothing to do with actually running it.
Except, if its embedded in vimscript, then it is intended to
On Aug 21, 2013 1:42 PM, Charles Campbell charles.e.campb...@nasa.gov
wrote:
LCD 47 wrote:
..snip..
+1 for this. People routinely edit files that only make sense (and
will only ever run) on remote servers. There are legitimate situations
where editing a file has nothing to do with
Bram Moolenaar wrote:
Manuel Ortega wrote:
As noted in an earlier thread, I discovered that most attributes to
:command can be abbreviated. I discovered this only by accident, looking
in syntax/vim.vim.
Turns out, in that syntax file (a) there is no support for the attribute
-buffer (for
James McCoy wrote:
On Aug 21, 2013 1:42 PM, Charles Campbell
charles.e.campb...@nasa.gov mailto:charles.e.campb...@nasa.gov wrote:
LCD 47 wrote:
..snip..
+1 for this. People routinely edit files that only make sense
(and
will only ever run) on remote servers. There are
Just curious if any headway has been made on this lookbehind regex issue?
I only ask because it breaks a pretty popular JS syntax plugin.
On Tuesday, August 13, 2013 5:34:52 PM UTC-7, Amadeus Demarzi wrote:
Alright, so I am admittedly terrible with Regexes, but I think I did find
something.
I've been using Steve Losh's excellent Splice plugin to perform
merges under Perforce. This worked fine with Vim 7.3.882 but it
fails horribly with Vim 7.4. I have in my environment
P4MERGE=p4merge-splice
where p4merge-splice is the following script:
exec vim $1 $2 $3 $4 -c 'set
On Aug 21, 2013 11:56 PM, Gary Johnson garyj...@spocom.com wrote:
I've been using Steve Losh's excellent Splice plugin to perform
merges under Perforce. This worked fine with Vim 7.3.882 but it
fails horribly with Vim 7.4. I have in my environment
P4MERGE=p4merge-splice
where
On Wed, Aug 21, 2013 at 1:50 PM, Charles Campbell
charles.e.campb...@nasa.gov wrote:
Bram Moolenaar wrote:
So Dr. Chip, please add this attribute to the syntax file.
And Bram, please note this in the docs about -buffer too.
This is not really intended to work that way. It happens that
On 2013-08-22, Nikolay Pavlov wrote:
No, this is not a bug. Index of buffer within vim.buffers used to be an
unknown
integer: it was index of underlying C linked list of buffers. I changed the
code to make it more meaningful: now this index is buffer number. But there is
no buffer number
On Wed, Aug 21, 2013 at 06:41:37PM +0300, LCD 47 wrote:
On 21 August 2013, Marius Gedminas mar...@gedmin.as wrote:
On Wed, Aug 21, 2013 at 01:56:31PM +0300, LCD 47 wrote:
On 20 August 2013, David Barnett daviebd...@gmail.com wrote:
Ensure ./foo doesn't exist, and do
:call
Yep, your patch fixes the symptom, both for 'foo/' and 'foo//'. Better your
workaround in vim than my workaround in vimscript!
(BTW, the indentation in the patch looked a little screwy.)
David
On Wed, Aug 21, 2013 at 8:41 AM, LCD 47 lcd...@gmail.com wrote:
On 21 August 2013, Marius Gedminas
Hi!
On Tue, Aug 20, 2013 at 05:15:49PM +0200, Christian Brabandt wrote:
On Di, 20 Aug 2013, Marius Gedminas wrote:
Steps to reproduce:
echo au BufRead,BufNewFile * new|put ='some text'|setlocal pvw bug.vim
vim -u bug.vim newfile.txt
Expected behavior (which I get with vim
19 matches
Mail list logo
